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MIL.  STD-498 


FOREWORD 

1 .  This  Military  Standard  is  approved  for  use  by  all  Departments  and  Agencies  of  the 
Department  of  Defense. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data 
which  may  be  of  use  in  improving  this  document  should  be  addressed  to  SPAWAR  10-12, 
2451  Crystal  Drive  (CPK-5),  Arlington,  VA  22245-5200.  The  comments  may  be  submitted 
by  letter  or  by  using  the  Standardization  Document  Improvement  Proposal  (DD  Form  1426) 
appearing  at  the  end  of  this  document. 

3.  This  standard  merges  DOD-STD-21  67A  and  DOD-STD-7935A  to  define  a  set  of  activities 
and  documentation  suitable  for  the  development  of  both  weapon  systems  and  Automated 
Information  Systems.  A  conversion  guide  from  these  standards  to  MIL-STD-498  is  provided 
in  Appendix  I.  Other  changes  include  improved  compatibility  with  incremental  and 
evolutionary  development  models;  improved  compatibility  with  non-hierarchical  design 
methods;  improved  compatibility  with  computer-aided  software  engineering  (CASE)  tools; 
alternatives  to,  and  more  flexibility  in,  preparing  documents;  clearer  requirements  for 
incorporating  reusable  software;  introduction  of  software  management  indicators;  added 
emphasis  on  software  supportability;  and  improved  links  to  systems  engineering.  This 
standard  supersedes  DOD-STD-21 67A,  DOD-STD-7935A,  and  D0D-STD-1703  (NS). 

4.  This  standard  can  be  applied  in  any  phase  of  the  system  life  cycle.  It  can  be  applied  to 
contractors,  subcontractors,  or  Government  in-house  agencies  performing  software 
development.  For  uniformity,  the  term  "acquirer”  is  used  for  the  organization  requiring  the 
technical  effort,  the  term  "developer"  for  the  organization  performing  the  technical  effort,  and 
the  term  "contract"  for  the  agreement  between  them.  The  term  "software  development"  is 
used  as  an  inclusive  term  encompassing  new  development,  modification,  reuse,  reengineering, 
maintenance,  and  all  other  activities  resulting  in  software  products. 

5.  This  standard  is  not  intended  to  specify  or  discourage  the  use  of  any  particular  software 
development  method.  The  developer  is  responsible  for  selecting  software  development 
methods  that  support  the  achievement  of  contract  requirements. 

6.  This  standard  implements  the  development  and  documentation  processes  of  ISO/IEC  DIS 
12207.  It  interprets  all  applicable  clauses  in  MIL-Q-9858A  (Quality  Program  Requirements) 
and  ISO  9001  (Quality  Systems)  for  software. 

7.  This  standard  includes  all  activities  pertaining  to  software  development.  It  invokes  no 
other  standards.  It  can  be  applied  on  its  own  or  supplemented  with  other  standards,  such  as 
those  identified  in  Section  6.  If  other  standards  are  applied,  the  acquirer  is  responsible  for 
resolving  any  conflicts  that  arise. 

8.  Data  Item  Descriptions  (DIDs)  applicable  to  this  standard  are  listed  in  Section  6.  These 
DIDs  describe  the  information  required  by  this  standard. 

9.  This  standard  and  its  Data  Item  Descriptions  (DIDs)  are  meant  to  be  tailored  by  the 
acquirer  to  ensure  that  only  necessary  and  cost-effective  requirements  are  imposed  on 
software  development  efforts.  General  tailoring  guidance  can  be  found  in  Section  6  and  in 
DOD-HDBK-248.  Tailoring  guidance  specific  to  this  standard  can  be  found  in  Appendixes  G 
and  H  and  in  guidebooks  and  handbooks  planned  for  this  standard. 
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1.  SCOPE 

1.1  Purpose.  The  purpose  of  this  standard  is  to  establish  uniform  requirements  for 
software  development  and  documentation. 

1.2  Application.  MIL-STD-498  is  intended  to  be  applied  as  follows. 

1.2.1  Organizations  and  agreements.  This  standard  can  be  applied  to  contractors, 
subcontractors,  or  Government  in-house  agencies  performing  software  development.  For 
uniformity,  the  term  "acquirer"  is  used  for  the  organization  requiring  the  technical  effort, 
"developer"  for  the  organization  performing  the  technical  effort,  "contract"  for  the  agreement 
between  these  parties,  "Statement  of  Work"  (SOW)  for  the  list  of  tasks  to  be  performed  by 
the  developer,  "Contract  Data  Requirements  List"  (CDRL)  for  the  list  of  deliverable  software 
products,  and  "subcontractor"  for  any  organization  tasked  by  the  developer  to  perform  part 
of  the  required  effort.  "Software  development"  is  used  as  an  inclusive  term  encompassing 
new  development,  modification,  reuse,  reengineering,  maintenance,  and  ail  other  activities 
resulting  in  software  products. 

1 .2.2  Contract-specific  application.  This  standard  is  invoked  by  citing  it  on  a  contract.  It 
applies  to  each  software  product  and  to  each  type  of  software  covered  by  the  contract, 
regardless  of  storage  medium,  to  the  extent  specified  in  the  contract.  Examples  of  types  of 
software  include  deliverable  versus  non-deliverable,  software  designed  to  meet  user  needs 
versus  software  in  the  engineering  and  test  environments,  and  software  designed  to  meet  one 
user  need  versus  software  designed  to  meet  another.  The  acquirer  is  expected  to  specify  the 
types  of  software  to  which  the  standard  applies  and  to  tailor  the  standard  appropriately  for 
each  type  of  software.  If  the  standard  is  invoked  without  such  a  statement  of  selective 
application,  it  will  be  understood  to  apply  in  its  entirety  to  all  deliverable  software,  with 
requirements  concerning  the  software  development  environment  applicable  to  the  software 
development  environment  for  the  deliverable  software.  While  this  standard  is  written  in  terms 
of  Computer  Software  Configuration  Items  (CSCIs),  it  may  be  applied  to  software  not 
designated  as  a  CSCI,  with  the  term  "CSCI"  interpreted  appropriately.  Software  installed  in 
firmware  is  subject  to  all  of  the  aforementioned  provisions.  This  standard  does  not  apply  to 
the  hardware  element  of  firmware. 

1 .2.3  Tailoring.  This  standard  and  its  Data  Item  Descriptions  (DIDs)  are  meant  to  be  tailored 
for  each  type  of  software  to  which  they  are  applied.  While  tailoring  is  the  responsibility  of  the 
acquirer,  suggested  tailoring  may  be  provided  by  prospective  and  selected  developers. 
General  tailoring  guidance  can  be  found  in  Section  6  and  in  DOD-HDBK-248.  Tailoring 
guidance  specific  to  this  standard  can  be  found  in  Appendixes  G  and  H  and  in  guidebooks  and 
handbooks  planned  for  this  standard. 

1 .2.4  Interpretation  of  selected  terms.  The  following  terms  have  a  special  interpretation  as 
used  in  this  standard. 

1.2. 4.1  Interpretation  of  "system".  The  following  interpretations  apply: 

a.  The  term  "system,"  as  used  in  this  standard,  may  mean:  (1)  a  hardware-software 
system  (for  example,  a  radar  system)  for  which  this  standard  covers  only  the  software 
portion,  or  (2)  a  software  system  (for  example,  a  payroll  system)  for  which  this 
standard  governs  overall  development. 
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b.  If  a  system  consists  of  subsystems,  all  requirements  in  this  standard  concerning 
systems  apply  to  the  subsystems  as  well.  If  a  contract  is  based  on  alternatives  to 
systems  and  subsystems,  such  as  complex  items,  the  requirements  in  this  standard 
concerning  the  system  and  its  specification  apply  to  these  alternatives  and  their 
specifications. 

1.2. 4. 2  Interpretation  of  ''participate"  in  system  development.  The  term  "participate"  in 
paragraphs  regarding  system-level  activities  is  to  be  interpreted  as  follows:  If  the  software 
covered  by  this  standard  is  part  of  a  hardware-software  system  for  which  this  standard  covers 
only  the  software  portion,  the  term  "participate"  is  to  be  interpreted  as  "take  part  in,  as 
described  in  the  software  development  plan."  If  the  software  (possibly  with  its  computers) 
is  considered  to  constitute  a  system,  the  term  "participate"  is  to  be  interpreted  as  "be 
responsible  for." 

1.2.4. 3  Interpretation  of  "develop."  "define."  etc.  Throughout  this  standard,  requirements 
to  "develop,"  "define,"  "establish,"  or  "identify"  information  are  to  be  interpreted  to  include 
new  development,  modification,  reuse,  reengineering,  maintenance,  or  any  other  activity  or 
combination  of  activities  resulting  in  software  products. 

1.2. 4. 4  Interpretation  of  "record".  Throughout  this  standard,  requirements  to  "record" 
information  are  to  be  interpreted  to  mean  "set  down  in  a  manner  that  can  be  retrieved  and 
viewed."  The  result  may  take  many  forms,  including,  but  not  limited  to,  hand-written  notes, 
hard-copy  or  electronic  documents,  and  data  recorded  in  computer-aided  software  engineering 
(CASE)  and  project  management  tools. 

1.3  Order  of  precedence.  In  the  event  of  conflict  between  the  requirements  of  this 
standard  and  other  applicable  standardization  documents,  the  acquirer  is  responsible  for 
resolving  the  conflicts. 
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2.  REFERENCED  DOCUMENTS 

This  section  does  not  apply  to  this  standard,  since  no  documents  are  referenced  in  Sections 
3,  4,  or  5.  Section  6  contains  a  list  of  standardization  documents  that  may  be  used  with  this 
standard. 
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3.  DEFINITIONS 

Note:  In  addition  to  the  definitions  provided  here,  Section  1  describes  MIL-STD-498's 
interpretation  or  special  usage  of  the  following  terms:  acquirer,  contract.  Contract  Data 
Requirements  List,  define,  develop,  developer,  establish,  identify,  participate,  record, 
software  development.  Statement  of  Work,  subcontractor,  subsystem,  and  system. 

3.1  Acceptance.  An  action  by  an  authorized  representative  of  the  acquirer  by  which  the 
acquirer  assumes  ownership  of  software  products  as  partial  or  complete  performance  of  a 
contract. 

3.2  Acquirer.  An  organization  that  procures  software  products  for  itself  or  another 
organization. 

3.3  Approval.  Written  notification  by  an  authorized  representative  of  the  acquirer  that  a 
developer's  plans,  design,  or  other  aspects  of  the  project  appear  to  be  sound  and  can  be  used 
as  the  basis  for  further  work.  Such  approval  does  not  shift  responsibility  from  the  developer 
to  meet  contractual  requirements. 

3.4  Architecture.  The  organizational  structure  of  a  system  or  CSCI,  identifying  its 
components,  their  interfaces,  and  a  concept  of  execution  among  them. 

3.5  Associate  developer.  An  organization  that  is  neither  prime  contractor  nor 
subcontractor  to  the  developer,  but  who  has  a  development  role  on  the  same  or  related 
system  or  project. 

3.6  Behavioral  design.  The  design  of  how  an  overall  system  or  CSCI  will  behave,  from  a 
user's  point  of  view,  in  meeting  its  requirements,  ignoring  the  internal  implementation  of  the 
system  or  CSCI.  This  design  contrasts  with  architectural  design,  which  identifies  the  internal 
components  of  the  system  or  CSCI,  and  with  the  detailed  design  of  those  components. 

3.7  Build.  (1)A  version  of  software  that  meets  a  specified  subset  of  the  requirements  that 
the  completed  software  will  meet.  (2)  The  period  of  time  during  which  such  a  version  is 
developed.  Note:  The  relationship  of  the  terms  "build"  and  "version"  is  up  to  the  developer; 
for  example,  it  may  take  several  versions  to  reach  a  build,  a  build  may  be  released  in  several 
parallel  versions  (such  as  to  different  sites),  or  the  terms  may  be  used  as  synonyms. 

3.8  Computer  database.  See  database. 

3.9  Computer  hardware.  Devices  capable  of  accepting  and  storing  computer  data, 
executing  a  systematic  sequence  of  operations  on  computer  data,  or  producing  control 
outputs.  Such  devices  can  perform  substantial  interpretation,  computation,  communication, 
control,  or  other  logical  functions. 

3.10  Computer  program.  A  combination  of  computer  instructions  and  data  definitions  that 
enable  computer  hardware  to  perform  computational  or  control  functions. 

3.11  Computer  software.  See  software. 
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3.12  Computer  Software  Configuration  Item  (CSCI).  An  aggregation  of  software  that 
satisfies  an  end  use  function  and  is  designated  for  separate  configuration  management  by  the 
acquirer.  CSCIs  are  selected  based  on  tradeoffs  among  software  function,  size,  host  or  target 
computers,  developer,  support  concept,  plans  for  reuse,  criticality,  interface  considerations, 
need  to  be  separately  documented  and  controlled,  and  other  factors. 

3.13  Configuration  Item.  An  aggregation  of  hardware,  software,  or  both  that  satisfies  an 
end  use  function  and  is  designated  for  separate  configuration  management  by  the  acquirer. 

3.14  Database.  A  collection  of  related  data  stored  in  one  or  more  computerized  files  in  a 
manner  that  can  be  accessed  by  users  or  computer  programs  via  a  database  management 
system. 

3.15  Database  management  system.  An  integrated  set  of  computer  programs  that  provide 
the  capabilities  needed  to  establish,  modify,  make  available,  and  maintain  the  integrity  of  a 
database. 

3.16  Deliverable  software  product.  A  software  product  that  is  required  by  the  contract  to 
be  delivered  to  the  acquirer  or  other  designated  recipient. 

3.17  Design.  Those  characteristics  of  a  system  or  CSCI  that  are  selected  by  the  developer 
in  response  to  the  requirements.  Some  will  match  the  requirements;  others  will  be 
elaborations  of  requirements,  such  as  definitions  of  all  error  messages  in  response  to  a 
requirement  to  display  error  messages;  others  will  be  implementation  related,  such  as 
decisions  about  what  software  units  and  logic  to  use  to  satisfy  the  requirements, 

3. 1 8  Developer.  An  organization  that  develops  software  products  ("develops"  may  include 
new  development,  modification,  reuse,  reengineering,  maintenance,  or  any  other  activity  that 
results  in  software  products).  The  developer  may  be  a  contractor  or  a  Government  agency. 

3.19  Document/documentation.  A  collection  of  data,  regardless  of  the  medium  on  which 
it  is  recorded,  that  generally  has  permanence  and  can  be  read  by  humans  or  machines. 

3.20  Evaluation.  The  process  of  determining  whether  an  item  or  activity  meets  specified 
criteria. 

3.21  Firmware.  The  combination  of  a  hardware  device  and  computer  instructions  and/or 
computer  data  that  reside  as  read-only  software  on  the  hardware  device. 

3.22  Hardware  Configuration  Item  (HWCI).  An  aggregation  of  hardware  that  satisfies  an 
end  use  function  and  is  designated  for  separate  configuration  management  by  the  acquirer. 

3.23  Independent  verification  and  validation  (IV&V).  Systematic  evaluation  of  software 
products  and  activities  by  an  agency  that  is  not  responsible  for  developing  the  product  or 
performing  the  activity  being  evaluated.  IV&V  is  not  within  the  scope  of  this  standard. 

3.24  Interface.  In  software  development,  a  relationship  among  two  or  more  entities  (such 
as  CSCI-CSCI,  CSCI-HWCI,  CSCI-user,  or  software  unit-software  unit)  in  which  the  entities 
share,  provide,  or  exchange  data.  An  interface  is  not  a  CSCI,  software  unit,  or  other  system 
component;  it  is  a  relationship  among  them. 
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3.25  Joint  review.  A  process  or  meeting  involving  representatives  of  both  the  acquirer  and 
the  developer,  during  which  project  status,  software  products,  and/or  project  issues  are 
examined  and  discussed. 

3.26  Non-deliverable  software  product.  A  software  product  that  is  not  required  by  the 
contract  to  be  delivered  to  the  acquirer  or  other  designated  recipient. 

3.27  Process.  An  organized  set  of  activities  performed  for  a  given  purpose;  for  example, 
the  software  development  process. 

3.28  Qualification  testing.  Testing  performed  to  demonstrate  to  the  acquirer  that  a  CSCI 
or  a  system  meets  its  specified  requirements. 

3.29  Reengineering.  The  process  of  examining  and  altering  an  existing  system  to 
reconstitute  it  in  a  new  form.  May  include  reverse  engineering  (analyzing  a  system  and 
producing  a  representation  at  a  higher  level  of  abstraction,  such  as  design  from  code), 
restructuring  (transforming  a  system  from  one  representation  to  another  at  the  same  level  of 
abstraction),  redocumentation  (analyzing  a  system  and  producing  user  or  support 
documentation),  forward  engineering  (using  software  products  derived  from  an  existing 
system,  together  with  new  requirements,  to  produce  a  new  system),  retargeting  (transforming 
a  system  to  install  it  on  a  different  target  system),  and  translation  (transforming  source  code 
from  one  language  to  another  or  from  one  version  of  a  language  to  another). 

3.30  Requirement.  (1 )  A  characteristic  that  a  system  or  CSCI  must  possess  in  order  to  be 
acceptable  to  the  acquirer.  (2)  A  mandatory  statement  in  this  standard  or  another  portion  of 
the  contract. 

3.31  Reusable  software  product.  A  software  product  developed  for  one  use  but  having 
other  uses,  or  one  developed  specifically  to  be  usable  on  multiple  projects  or  in  multiple  roles 
on  one  project.  Examples  include,  but  are  not  limited  to,  commercial  off-the-shelf  software 
products,  acquirer-furnished  software  products,  software  products  in  reuse  libraries,  and  pre¬ 
existing  developer  software  products.  Each  use  may  include  all  or  part  of  the  software 
product  and  may  involve  its  modification.  This  term  can  be  applied  to  any  software  product 
(for  example,  requirements,  architectures,  etc.),  not  just  to  software  itself. 

3.32  Software.  Computer  programs  and  computer  databases.  Note:  Although  some 
definitions  of  software  include  documentation,  MIL-STD-498  limits  the  definition  to  computer 
programs  and  computer  databases  in  accordance  with  Defense  Federal  Acquisition  Regulation 
Supplement  227.401. 

3.33  Software  development.  A  set  of  activities  that  results  in  software  products.  Software 
development  may  include  new  development,  modification,  reuse,  reengineering,  maintenance, 
or  any  other  activities  that  result  in  software  products. 

3.34  Software  development  file  (SDF).  A  repository  for  material  pertinent  to  the 
development  of  a  particular  body  of  software.  Contents  typically  include  (either  directly  or 
by  reference)  considerations,  rationale,  and  constraints  related  to  requirements  analysis, 
design,  and  implementation;  developer-internal  test  information;  and  schedule  and  status 
information. 

3.35  Software  development  library  (SDL).  A  controlled  collection  of  software,  documen¬ 
tation,  other  intermediate  and  final  software  products,  and  associated  tools  and  procedures 
used  to  facilitate  the  orderly  development  and  subsequent  support  of  software. 


6 


MIL-STD-498 


3.36  Software  development  process.  An  organized  set  of  activities  performed  to  translate 
user  needs  into  software  products. 

3.37  Software  engineering.  In  general  usage,  a  synonym  for  software  development.  As 
used  in  this  standard,  a  subset  of  software  development  consisting  of  all  activities  except 
qualification  testing.  The  standard  makes  this  distinction  for  the  sole  purpose  of  giving 
separate  names  to  the  software  engineering  and  software  test  environments. 

3.38  Software  engineering  environment.  The  facilities,  hardware,  software,  firmware, 
procedures,  and  documentation  needed  to  perform  software  engineering.  Elements  may 
include  but  are  not  limited  to  computer-aided  software  engineering  (CASE)  tools,  compilers, 
assemblers,  linkers,  loaders,  operating  systems,  debuggers,  simulators,  emulators, 
documentation  tools,  and  database  management  systems. 

3.39  Software  product.  Software  or  associated  information  created,  modified,  or  incor¬ 
porated  to  satisfy  a  contract.  Examples  include  plans,  requirements,  design,  code,  databases, 
test  information,  and  manuals. 

3.40  Software  quality.  The  ability  of  software  to  satisfy  its  specified  requirements. 

3.41  Software  support.  The  set  of  activities  that  takes  place  to  ensure  that  software 
installed  for  operational  use  continues  to  perform  as  intended  and  fulfill  its  intended  role  in 
system  operation.  Software  support  includes  software  maintenance,  aid  to  users,  and  related 
activities. 

3.42  Software  system.  A  system  consisting  solely  of  software  and  possibly  the  computer 
equipment  on  which  the  software  operates. 

3.43  Software  test  environment.  The  facilities,  hardware,  software,  firmware,  procedures, 
and  documentation  needed  to  perform  qualification,  and  possibly  other,  testing  of  software. 
Elements  may  include  but  are  not  limited  to  simulators,  code  analyzers,  test  case  generators, 
and  path  analyzers,  and  may  also  include  elements  used  in  the  software  engineering 
environment. 

3.44  Software  transition.  The  set  of  activities  that  enables  responsibility  for  software 
development  to  pass  from  one  organization,  usually  the  organization  that  performs  initial 
software  development,  to  another,  usually  the  organization  that  will  perform  software  support. 

3.45  Software  unit.  An  element  in  the  design  of  a  CSCI;  for  example,  a  major  subdivision 
of  a  CSCI,  a  component  of  that  subdivision,  a  class,  object,  module,  function,  routine,  or 
database.  Software  units  may  occur  at  different  levels  of  a  hierarchy  and  may  consist  of 
other  software  units.  Software  units  in  the  design  may  or  may  not  have  a  one-to-one 
relationship  with  the  code  and  data  entities  (routines,  procedures,  databases,  data  files,  etc.) 
that  implement  them  or  with  the  computer  files  containing  those  entities. 

3.46  Support  (of  software).  See  software  support. 

3.47  Transition  (of  software).  See  software  transition. 

3.48  Definitions  of  acronyms  used  in  this  standard.  See  Appendix  A. 
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4.  GENERAL  REQUIREMENTS 

4.1  Software  development  process.  The  developer  shall  establish  a  software  development 
process  consistent  with  contract  requirements.  The  software  development  process  shall 
include  the  following  major  activities,  which  may  overlap,  may  be  applied  iteratively,  may  be 
applied  differently  to  different  elements  of  software,  and  need  not  be  performed  in  the  order 
listed  below.  Appendix  G  provides  examples.  The  developer's  software  development  process 
shall  be  described  in  the  software  development  plan. 

a.  Project  planning  and  oversight  (section  5.1) 

b.  Establishing  a  software  development  environment  (5.2) 

c.  System  requirements  analysis  (5.3) 

d.  System  design  (5.4) 

e.  Software  requirements  analysis  (5.5) 

f.  Software  design  (5.6) 

g.  Software  implementation  and  unit  testing  (5.7) 

h.  Unit  integration  and  testing  (5.8) 

i.  CSCI  qualification  testing  (5.9) 

j.  CSCI/HWCI  integration  and  testing  (5.10) 

k.  System  qualification  testing  (5.1 1) 

l.  Preparing  for  software  use  (5.1 2) 

m.  Preparing  for  software  transition  (5.13) 

n.  Integral  processes: 

1)  Software  configuration  management  (5.14) 

2)  Software  product  evaluation  (5.15) 

3)  Software  quality  assurance  (5.16) 

4)  Corrective  action  (5.17) 

5)  Joint  technical  and  management  reviews  (5.18) 

6)  Other  activities  (5.19) 

4.2  General  requirements  for  software  development.  The  developer  shall  meet  the 
following  general  requirements  in  carrying  out  the  detailed  requirements  in  section  5  of  this 
standard. 

4.2.1  Software  development  methods.  The  developer  shall  use  systematic,  documented 
methods  for  all  software  development  activities.  These  methods  shall  be  described  in,  or 
referenced  from,  the  software  development  plan. 

4.2.2  Standards  for  software  products.  The  developer  shall  develop  and  apply  standards  for 
representing  requirements,  design,  code,  test  cases,  test  procedures,  and  test  results.  These 
standards  shall  be  described  in,  or  referenced  from,  the  software  development  plan. 

4.2.3  Reusable  software  products.  The  developer  shall  meet  the  following  requirements. 

4.2.3. 1  Incorporating  reusable  software  products.  The  developer  shall  identify  and  evaluate 
reusable  software  products  for  use  in  fulfilling  the  requirements  of  the  contract.  The  scope 
of  the  search  and  the  criteria  to  be  used  for  evaluation  shall  be  as  described  in  the  software 
development  plan.  Reusable  software  products  that  meet  the  criteria  shall  be  used  where 
practical.  Appendix  B  provides  required  and  candidate  criteria  and  interprets  this  standard  for 
incorporation  of  reusable  software  products.  Incorporated  software  products  shall  meet  the 
data  rights  requirements  in  the  contract. 
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4. 2. 3. 2  Developing  reusable  software  products.  During  the  course  of  the  contract,  the 
developer  shall  identify  opportunities  for  developing  software  products  for  reuse  and  shall 
evaluate  the  benefits  and  costs  of  these  opportunities.  Opportunities  that  provide  cost 
benefits  and  are  compatible  with  program  objectives  shall  be  identified  to  the  acquirer. 

Note:  In  addition,  the  developer  may  be  required  by  the  contract  to  develop  software 

products  specifically  for  reuse. 

4.2.4  Handling  of  critical  requirements.  The  developer  shall  meet  the  following  requirements. 

4.2.4. 1  Safety  assurance.  The  developer  shall  identify  as  safety-critical  those  CSCIs  or 
portions  thereof  whose  failure  could  lead  to  a  hazardous  system  state  (one  that  could  result 
in  unintended  death,  injury,  loss  of  property,  or  environmental  harm).  If  there  is  such 
software,  the  developer  shail  develop  a  safety  assurance  strategy,  including  both  tests  and 
analyses,  to  assure  that  the  requirements,  design,  implementation,  and  operating  procedures 
for  the  identified  software  minimize  or  eliminate  the  potential  for  hazardous  conditions.  The 
strategy  shall  include  a  software  safety  program,  which  shall  be  integrated  with  the  system 
safety  program  if  one  exists.  The  developer  shall  record  the  strategy  in  the  software 
development  plan,  implement  the  strategy,  and  produce  evidence,  as  part  of  required  software 
products,  that  the  safety  assurance  strategy  has  been  carried  out. 

4. 2. 4. 2  Security  assurance.  The  developer  shall  identify  as  security-critical  those  CSCIs  or 
portions  thereof  whose  failure  could  lead  to  a  breach  of  system  security.  If  there  is  such 
software,  the  developer  shall  develop  a  security  assurance  strategy  to  assure  that  the 
requirements,  design,  implementation,  and  operating  procedures  for  the  identified  software 
minimize  or  eliminate  the  potential  for  breaches  of  system  security.  The  developer  shall  record 
the  strategy  in  the  software  development  plan,  implement  the  strategy,  and  produce  evidence, 
as  part  of  required  software  products,  that  the  security  assurance  strategy  has  been  carried 
out. 

4. 2. 4. 3  Privacy  assurance.  The  developer  shall  identify  as  privacy-critical  those  CSCIs  or 
portions  thereof  whose  failure  could  lead  to  a  breach  of  system  privacy.  If  there  is  such 
software,  the  developer  shall  develop  a  privacy  assurance  strategy  to  assure  that  the 
requirements,  design,  implementation,  and  operating  procedures  for  the  identified  software 
minimize  or  eliminate  the  potential  for  breaches  of  system  privacy.  The  developer  shall  record 
the  strategy  in  the  software  development  plan,  implement  the  strategy,  and  produce  evidence, 
as  part  of  required  software  products,  that  the  privacy  assurance  strategy  has  been  carried 
out. 

4. 2.4.4  Assurance  of  other  critical  requirements.  If  a  system  relies  on  software  to  satisfy 
other  requirements  deemed  critical  by  the  contract  or  by  system  specifications,  the  developer 
shall  identify  those  CSCIs  or  portions  thereof  whose  failure  could  lead  to  violation  of  those 
critical  requirements;  develop  a  strategy  to  assure  that  the  requirements,  design, 
implementation,  and  operating  procedures  for  the  identified  software  minimize  or  eliminate  the 
potential  for  such  violations;  record  the  strategy  in  the  software  development  plan;  implement 
She  strategy;  and  produce  evidence,  as  part  of  required  software  products,  that  the  assurance 
strategy  has  been  carried  out. 
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4.2.5  Computer  hardware  resource  utilization.  The  developer  shall  analyze  contract  require¬ 
ments  concerning  computer  hardware  resource  utilization  (such  as  maximum  allowable  use 
of  processor  capacity,  memory  capacity,  input/output  device  capacity,  auxiliary  storage  device 
capacity,  and  communications/network  equipment  capacity).  The  developer  shall  allocate 
computer  hardware  resources  among  the  CSCIs,  monitor  the  utilization  of  these  resources  for 
the  duration  of  the  contract,  and  reallocate  or  identify  the  need  for  additional  resources  as 
necessary  to  meet  contract  requirements. 

4.2.6  Recording  rationale.  The  developer  shall  record  rationale  that  will  be  useful  to  the 
support  agency  for  key  decisions  made  in  specifying,  designing,  implementing,  and  testing  the 
software.  The  rationale  shall  include  trade-offs  considered,  analysis  methods,  and  criteria 
used  to  make  the  decisions.  The  rationale  shall  be  recorded  in  documents,  code  comments, 
or  other  media  that  will  transition  to  the  support  agency.  The  meaning  of  "key  decisions"  and 
the  approach  for  providing  the  rationale  shall  be  described  in  the  software  development  plan. 

4.2.7  Access  for  acquirer  review.  The  developer  shall  provide  the  acquirer  or  its  authorized 
representative  access  to  developer  and  subcontractor  facilities,  including  the  software 
engineering  and  test  environments,  for  review  of  software  products  and  activities  required  by 
the  contract. 
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5.  DETAILED  REQUIREMENTS 

The  order  of  the  requirements  in  this  section  is  not  intended  to  specify  the  order  in  which  they 
must  be  carried  out.  Many  of  the  activities  may  be  ongoing  at  one  time;  different  software 
products  may  proceed  at  different  paces;  and  activities  specified  in  early  subsections  may 
depend  on  input  from  activities  in  later  subsections.  If  the  software  is  developed  in  multiple 
builds,  some  activities  may  be  performed  in  every  build,  others  may  be  performed  only  in 
selected  builds,  and  activities  and  software  products  may  not  be  complete  until  several  or  all 
builds  are  accomplished.  Figure  1  provides  an  example  of  how  each  activity  may  be  applied 
in  one  or  more  builds.  Non-mandatory  notes  throughout  section  5  tell  how  to  interpret  each 
activity  on  a  project  involving  multiple  builds.  A  project  involving  a  single  build  will 
accomplish  all  required  activities  in  that  build.  Appendix  G  provides  guidance  for  planning 
builds,  determining  which  activities  apply  to  each  build,  and  scheduling  these  activities. 


5.1  Project  planning  and  oversight 


5.2  Establishing  a  software  development  environment 


5.3  System  requirements  analysis 


5.4  System  design 


5.5  Software  requirements  analysis 


5.6  Software  design 


5.7  Software  implementation  and  unit  testing 


5.8  Unit  integration  and  testing 


5.9  CSCI  qualification  testing 


5.10  CSCI/HWCI  integration  and  testing 


5.11  System  qualification  testing 


5.12  Preparing  for  software  use 


5.13  Preparing  for  software  transition 


Integral  processes: 


5.14  Software  configuration  management 


5.15  Software  product  evaluation 


5.16  Software  quality  assurance 


5.17  Corrective  action 


5.18  Joint  technical  and  management  reviews 


5.19  Other  activities 


FIGURE  1.  One  possible  mapping  of  MIL-STD-498  activities  to  multiple  builds. 
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5.1  Project  planning  and  oversight.  The  developer  shall  perform  project  planning  and 
oversight  in  accordance  with  the  following  requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  planning  for  each  build  should 
be  interpreted  to  include:  a)  overall  planning  for  the  contract,  b)  detailed  planning  for  the 
current  build,  and  c)  planning  for  future  builds  covered  under  the  contract  to  a  level  of 
detail  compatible  with  the  information  available. 

5.1.1  Software  development  planning.  The  developer  shall  develop  and  record  plans  for 
conducting  the  activities  required  by  this  standard  and  by  other  software-related  requirements 
in  the  contract.  This  planning  shall  be  consistent  with  system-level  planning  and  shall  include 
all  applicable  items  in  the  Software  Development  Plan  (SDP)  DID  (see  6.2). 

Note  1:  The  wording  here  and  throughout  MIL-STD-498  is  designed  to:  1 )  Emphasize  that 
the  development  and  recording  of  planning  and  engineering  information  is  an  intrinsic  part 
of  the  software  development  process,  to  be  performed  regardless  of  whether  a  deliverable 
is  required;  2)  Use  the  DID  as  a  checklist  of  items  to  be  covered  in  the  planning  or 
engineering  activity;  and  3)  Permit  representations  other  than  traditional  documents  for 
recording  the  information  (e.g.,  computer-aided  software  engineering  (CASE)  tools). 

Note  2:  If  the  CDRL  specifies  delivery  of  the  information  generated  by  this  or  any  other 
paragraph,  the  developer  is  required  to  format,  assemble,  mark,  copy,  and  distribute  the 
deliverable  in  accordance  with  the  CDRL.  This  task  is  recognized  to  be  separate  from  the 
task  of  generating  and  recording  the  required  information  and  to  require  additional  time  and 
effort  on  the  part  of  the  developer. 

Note  3:  The  software  development  plan  covers  all  activities  required  by  this  standard. 
Portions  of  the  plan  may  be  bound  or  maintained  separately  if  this  approach  enhances  the 
usability  of  the  information.  Examples  include  separate  plans  for  software  quality 
assurance  and  software  configuration  management. 

5.1.2  CSCI  test  planning.  The  developer  shall  develop  and  record  plans  for  conducting  CSCI 
qualification  testing.  This  planning  shall  include  all  applicable  items  in  the  Software  Test  Plan 
(STP)  DID  (see  6.2). 

5.1.3  System  test  planning.  The  developer  shall  participate  in  developing  and  recording  plans 
for  conducting  system  qualification  testing.  For  software  systems,  this  planning  shall  include 
all  applicable  items  in  the  Software  Test  Plan  (STP)  DID  (see  6.2).  (The  intent  for  software 
systems  is  a  single  software  test  plan  covering  both  CSCI  and  system  qualification  testing.) 

5.1.4  Software  installation  planning.  The  developer  shall  develop  and  record  plans  for 
performing  software  installation  and  training  at  the  user  sites  specified  in  the  contract.  This 
planning  shall  include  all  applicable  items  in  the  Software  Installation  Plan  (SIP)  DID  (see  6.2). 

5.1.5  Software  transition  planning.  The  developer  shall  identify  all  software  development 
resources  that  will  be  needed  by  the  support  agency  to  fulfill^ie  support  concept  specified 
in  the  contract.  The  developer  shall  develop  and  record  plans  identifying  these  resources  and 
describing  the  approach  to  be  followed  for  transitioning  deliverable  items  to  the  support 
agency.  This  planning  shall  include  all  applicable  items  in  the  Software  Transition  Plan  (STrP) 
DID  (see  6.2). 
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5.1.6  Following  and  updating  plans.  Following  acquirer  approval  of  any  of  the  plans  in  this 
section,  the  developer  shall  conduct  the  relevant  activities  in  accordance  with  the  plan.  The 
developer's  management  shall  review  the  software  development  process  at  intervals  specified 
in  the  software  development  plan  to  assure  that  the  process  complies  with  the  contract  and 
adheres  to  the  plans.  With  the  exception  of  developer-internal  scheduling  and  related  staffing 
information,  updates  to  plans  shall  be  subject  to  acquirer  approval. 

5.2  Establishing  a  software  development  environment.  The  developer  shall  establish  a 
software  development  environment  in  accordance  with  the  following  requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  establishing  the  software 
development  environment  in  each  build  should  be  interpreted  to  mean  establishing  the 
environment  needed  to  complete  that  build. 

5.2. 1  Software  engineering  environment.  The  developer  shall  establish,  control,  and  maintain 
a  software  engineering  environment  to  perform  the  software  engineering  effort.  The 
developer  shall  ensure  that  each  element  of  the  environment  performs  its  intended  functions. 

5.2.2  Software  test  environment.  The  developer  shall  establish,  control,  and  maintain  a 
software  test  environment  to  perform  qualification,  and  possibly  other,  testing  of  software. 
The  developer  shall  ensure  that  each  element  of  the  environment  performs  its  intended 
functions. 

5.2.3  Software  development  library.  The  developer  shall  establish,  control,  and  maintain  a 
software  development  library  (SDL)  to  facilitate  the  orderly  development  and  subsequent 
support  of  software.  The  SDL  may  be  an  integral  part  of  the  software  engineering  and  test 
environments.  The  developer  shall  maintain  the  SDL  for  the  duration  of  the  contract. 

5.2.4  Software  development  files.  The  developer  shall  establish,  control,  and  maintain  a 
software  development  file  (SDF)  for  each  software  unit  or  logically  related  group  of  software 
units,  for  each  CSCI,  and,  as  applicable,  for  logical  groups  of  CSCIs,  for  subsystems,  and  for 
the  overall  system.  The  developer  shall  record  information  about  the  development  of  the 
software  in  appropriate  SDFs  and  shall  maintain  the  SDFs  for  the  duration  of  the  contract. 

5.2.5  Non-deliverable  software.  The  developer  may  use  non-deliverable  software  in  the 
development  of  deliverable  software  as  long  as  the  operation  and  support  of  the  deliverable 
software  after  delivery  to  the  acquirer  do  not  depend  on  the  non-deliverable  software  or 
provision  is  made  to  ensure  that  the  acquirer  has  or  can  obtain  the  same  software.  The 
developer  shall  ensure  that  all  non-deliverable  software  used  on  the  project  performs  its 
intended  functions. 

5.3  System  requirements  analysis.  The  developer  shall  participate  in  system  requirements 
analysis  in  accordance  with  the  following  requirements. 

Note:  If  a  system  is  developed  in  multiple  builds,  its  requirements  may  not  be  fully  defined 
until  the  final  build.  The  developer's  planning  should  identify  the  subset  of  system 
requirements  to  be  defined  in  each  build  and  the  subset  to  be  implemented  in  each  build. 
System  requirements  analysis  for  a  given  build  should  be  interpreted  to  mean  defining  the 
system  requirements  so  identified  for  that  build. 
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5.3. 1  Analysis  of  user  input.  The  developer  shall  participate  in  analyzing  user  input  provided 
by  the  acquirer  to  gain  an  understanding  of  user  needs.  This  input  may  take  the  form  of  need 
statements,  surveys,  problem/change  reports,  feedback  on  prototypes,  interviews,  or  other 
user  input  or  feedback. 

5.3.2  Operational  concept.  The  developer  shall  participate  in  defining  and  recording  the 
operational  concept  for  the  system.  The  result  shall  include  all  applicable  items  in  the 
Operational  Concept  Description  (OCD)  DID  (see  6.2). 

5.3.3  System  requirements.  The  developer  shall  participate  in  defining  and  recording  the 
requirements  to  be  met  by  the  system  and  the  methods  to  be  used  to  ensure  that  each 
requirement  has  been  met.  The  result  shall  include  all  applicable  items  in  the  System/ 
Subsystem  Specification  (SSS)  DID  (see  6.2).  Depending  on  CDRL  provisions,  requirements 
concerning  system  interfaces  may  be  included  in  the  SSS  or  in  interface  requirements 
specifications  (IRSs). 

Note:  If  a  system  consists  of  subsystems,  the  activity  in  5.3.3  is  intended  to  be 
performed  iteratively  with  the  activities  in  5.4  (System  design)  to  define  system 
requirements,  design  the  system  and  identify  its  subsystems,  define  the  requirements  for 
those  subsystems,  design  the  subsystems  and  identify  their  components,  and  so  on. 

5.4  System  design.  The  developer  shall  participate  in  system  design  in  accordance  with  the 
following  requirements. 

Note:  If  a  system  is  developed  in  multiple  builds,  its  design  may  not  be  fully  defined  until 
the  final  build.  The  developer's  planning  should  identify  the  portion  of  the  system  design 
to  be  defined  in  each  build.  System  design  for  a  given  build  should  be  interpreted  to  mean 
defining  the  portion  of  the  system  design  identified  for  that  build. 

5.4.1  Svstem-wide  design  decisions.  The  developer  shall  participate  in  defining  and 
recording  system-wide  design  decisions  (that  is,  decisions  about  the  system's  behavioral 
design  and  other  decisions  affecting  the  selection  and  design  of  system  components).  The 
result  shall  include  all  applicable  items  in  the  system-wide  design  section  of  the 
System/Subsystem  Design  Description  (SSDD)  DID  (see  6.2).  Depending  on  CDRL  provisions, 
design  pertaining  to  interfaces  may  be  included  in  the  SSDD  or  in  interface  design  descriptions 
(IDDs)  and  design  pertaining  to  databases  may  be  included  in  the  SSDD  or  in  database  design 
descriptions  (DBDDs). 

Note:  Design  decisions  remain  at  the  discretion  of  the  developer  unless  formally  converted 
to  requirements  through  contractual  processes.  The  developer  is  responsible  for  fulfilling 
all  requirements  and  demonstrating  this  fulfillment  through  qualification  testing  (see  5.9, 
5.11).  Design  decisions  act  as  developer-internal  "requirements,"  to  be  implemented, 
imposed  on  subcontractors,  if  applicable,  and  confirmed  by  developer-internal  testing,  but 
their  fulfillment  need  not  be  demonstrated  to  the  acquirer. 

5.4.2  System  architectural  design.  The  developer  shall  participate  in  defining  and  recording 
the  architectural  design  of  the  system  (identifying  the  components  of  the  system,  their 
interfaces,  and  a  concept  of  execution  among  them)  and  the  traceability  between  the  system 
components  and  system  requirements.  The  result  shall  include  all  applicable  items  in  the 
architectural  design  and  traceability  sections  of  the  System/Subsystem  Design  Description 
(SSDD)  DID  (see  6.2).  Depending  on  CDRL  provisions,  design  pertaining  to  interfaces  may 
be  included  in  the  SSDD  or  in  interface  design  descriptions  (IDDs). 
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5.5  Software  requirements  analysis.  The  developer  shall  define  and  record  the  software 
requirements  to  be  met  by  each  CSCI,  the  methods  to  be  used  to  ensure  that  each 
requirement  has  been  met,  and  the  traceability  between  the  CSCI  requirements  and  system 
requirements.  The  result  shall  include  all  applicable  items  in  the  Software  Requirements 
Specification  (SRS)  DID  (see  6.2).  Depending  on  CDRL  provisions,  requirements  concerning 
CSCI  interfaces  may  be  included  in  SRSs  or  in  interface  requirements  specifications  (IRSs). 

Note:  If  a  CSCI  is  developed  in  multiple  builds,  its  requirements  may  not  be  fully  defined 
until  the  final  build.  The  developer's  planning  should  identify  the  subset  of  each  CSCI's 
requirements  to  be  defined  in  each  build  and  the  subset  to  be  implemented  in  each  build. 
Software  requirements  analysis  for  a  given  build  should  be  interpreted  to  mean  defining 
the  CSCI  requirements  so  identified  for  that  build. 

5.6  Software  design.  The  developer  shall  perform  software  design  in  accordance  with  the 
following  requirements. 

Note:  If  a  CSCI  is  developed  in  multiple  builds,  its  design  may  not  be  fully  defined  until  the 
final  build.  Software  design  in  each  build  should  be  interpreted  to  mean  the  design 
necessary  to  meet  the  CSCI  requirements  to  be  implemented  in  that  build. 

5.6.1  CSCI-wide  design  decisions.  The  developer  shall  define  and  record  CSCI-wide  design 
decisions  (that  is,  decisions  about  the  CSCI's  behavioral  design  and  other  decisions  affecting 
the  selection  and  design  of  the  software  units  comprising  the  CSCI).  The  result  shall  include 
all  applicable  items  in  the  CSCI-wide  design  section  of  the  Software  Design  Description  (SDD) 
DID  (see  6.2).  Depending  on  CDRL  provisions,  design  pertaining  to  interfaces  may  be  included 
in  SDDs  or  in  interface  design  descriptions  (IDDs)  and  design  pertaining  to  databases  may  be 
included  in  SDDs  or  in  database  design  descriptions  (DBDDs). 

5.6.2  CSCI  architectural  design.  The  developer  shall  define  and  record  the  architectural 
design  of  each  CSCI  (identifying  the  software  units  comprising  the  CSCI,  their  interfaces,  and 
a  concept  of  execution  among  them)  and  the  traceability  between  the  software  units  and  the 
CSCI  requirements.  The  result  shall  include  all  applicable  items  in  the  architectural  design  and 
traceability  sections  of  the  Software  Design  Description  (SDD)  DID  (see  6.2).  Depending  on 
CDRL  provisions,  design  pertaining  to  interfaces  may  be  included  in  SDDs  or  in  interface 
design  descriptions  (IDDs). 

Note:  Software  units  may  be  made  up  of  other  software  units  and  may  be  organized  into 
as  many  levels  as  are  needed  to  represent  the  CSCI  architecture.  For  example,  a  CSCI 
may  be  divided  into  three  software  units,  each  of  which  is  divided  into  additional  software 
units,  and  so  on. 

5.6.3  CSCI  detailed  desian.  The  developer  shall  develop  and  record  a  description  of  each 
software  unit.  The  result  shall  include  all  applicable  items  in  the  detailed  design  section  of  the 
Software  Design  Description  (SDD)  DID  (see  6.2).  Depending  on  CDRL  provisions,  design 
pertaining  to  interfaces  may  be  included  in  SDDs  or  in  interface  design  descri^ons  (IDDs)  and 
design  of  software  units  that  are  databases  or  that  access  or  manipulate  databases  may  be 
included  in  SDDs  or  in  database  design  descriptions  (DBDDs). 
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5.7  Software  implementation  and  unit  testing.  The  developer  shall  perform  software 
implementation  and  unit  testing  in  accordance  with  the  following  requirements. 

Note:  The  term  "software"  includes  both  computer  programs  and  computer  databases. 
The  term  "implementation"  means  converting  software  design  into  computer  programs  and 
computer  databases.  If  a  CSCI  is  developed  in  multiple  builds,  software  implementation 
and  unit  testing  of  that  CSCI  will  not  be  completed  until  the  final  build.  Software 
implementation  and  unit  testing  in  each  build  should  be  interpreted  to  include  those  units, 
or  parts  of  units,  needed  to  meet  the  CSCI  requirements  to  be  implemented  in  that  build. 

5.7.1  Software  implementation.  The  developer  shall  develop  and  record  software  corre¬ 
sponding  to  each  software  unit  in  the  CSCI  design.  This  activity  shall  include,  as  applicable, 
coding  computer  instructions  and  data  definitions,  building  databases,  populating  databases 
and  other  data  files  with  data  values,  and  other  activities  needed  to  implement  the  design. 
For  deliverable  software,  the  developer  shall  obtain  acquirer  approval  to  use  any  programming 
language  not  specified  in  the  contract. 

Note:  Software  units  in  the  design  may  or  may  not  have  a  one-to-one  relationship  with 
the  code  and  data  entities  (routines,  procedures,  databases,  data  files,  etc.)  that  implement 
them  or  with  the  computer  files  containing  those  entities. 

5.7.2  Preparing  for  unit  testing.  The  developer  shall  establish  test  cases  (in  terms  of  inputs, 
expected  results,  and  evaluation  criteria),  test  procedures,  and  test  data  for  testing  the 
software  corresponding  to  each  software  unit.  The  test  cases  shall  cover  all  aspects  of  the 
unit's  detailed  design.  The  developer  shall  record  this  information  in  the  appropriate  software 
development  files  (SDFs). 

5.7.3  Performing  unit  testing.  The  developer  shall  test  the  software  corresponding  to  each 
software  unit.  The  testing  shall  be  in  accordance  with  the  unit  test  cases  and  procedures. 

5.7.4  Revision  and  retesting.  The  developer  shall  make  all  necessary  revisions  to  the 
software,  perform  all  necessary  retesting,  and  update  the  software  development  files  (SDFs) 
and  other  software  products  as  needed,  based  on  the  results  of  unit  testing. 

5.7.5  Analyzing  and  recording  unit  test  results.  The  developer  shall  analyze  the  results  of 
unit  testing  and  shall  record  the  test  and  analysis  results  in  appropriate  software  development 
files  (SDFs). 

5.8  Unit  integration  and  testing.  The  developer  shall  perform  unit  integration  and  testing 
in  accordance  with  the  following  requirements. 

Note  1 :  Unit  integration  and  testing  means  integrating  the  software  corresponding  to  two 
or  more  software  units,  testing  the  resulting  software  to  ensure  that  it  works  together  as 
intended,  and  continuing  this  process  until  all  software  in  each  CSCI  is  integrated  and 
tested.  The  last  stage  of  this  testing  is  developer-internal  CSCI  testing.  Since  units  may 
consist  of  other  units,  some  unit  integration  and  testing  may  take  place  during  unit  testing. 
The  requirements  in  this  section  are  not  meant  to  duplicate  those  activities. 

Note  2:  If  a  CSCI  is  developed  in  multiple  builds,  unit  integration  and  testing  of  that  CSCI 
will  not  be  completed  until  the  final  build.  Unit  integration  and  testing  in  each  build  should 
be  interpreted  to  mean  integrating  software  developed  in  the  current  build  with  other 
software  developed  in  that  and  previous  builds,  and  testing  the  results. 
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5.8.1  Preparing  for  unit  integration  and  testing.  The  developer  shall  establish  test  cases  (in 
terms  of  inputs,  expected  results,  and  evaluation  criteria),  test  procedures,  and  test  data  for 
conducting  unit  integration  and  testing.  The  test  cases  shall  cover  all  aspects  of  the  CSCI- 
wide  and  CSCI  architectural  design.  The  developer  shall  record  this  information  in  the 
appropriate  software  development  files  (SDFs). 

5.8.2  Performing  unit  integration  and  testing.  The  developer  shall  perform  unit  integration 
and  testing.  The  testing  shall  be  in  accordance  with  the  unit  integration  test  cases  and 
procedures. 

5.8.3  Revision  and  retesting.  The  developer  shall  make  all  necessary  revisions  to  the 
software,  perform  all  necessary  retesting,  and  update  the  software  development  files  (SDFs) 
and  other  software  products  as  needed,  based  on  the  results  of  unit  integration  and  testing. 

5.8.4  Analyzing  and  recording  unit  integration  and  test  results.  The  developer  shall  analyze 
the  results  of  unit  integration  and  testing  and  shall  record  the  test  and  analysis  results  in 
appropriate  software  development  files  (SDFs). 

5.9  CSCI  qualification  testing.  The  developer  shall  perform  CSCI  qualification  testing  in 
accordance  with  the  following  requirements. 

Note  1 :  CSCI  qualification  testing  is  performed  to  demonstrate  to  the  acquirer  that  CSCI 
requirements  have  been  met.  It  covers  the  CSCI  requirements  in  software  requirements 
specifications  (SRSs)  and  in  associated  interface  requirements  specifications  (IRSs).  This 
testing  contrasts  with  developer-internal  CSCI  testing,  performed  as  the  final  stage  of  unit 
integration  and  testing. 

Note  2:  If  a  CSCI  is  developed  in  multiple  builds,  its  CSCI  qualification  testing  will  not  be 
completed  until  the  final  build  for  that  CSCI,  or  possibly  until  later  builds  involving  items 
with  which  the  CSCI  is  required  to  interface.  CSCI  qualification  testing  in  each  build 
should  be  interpreted  to  mean  planning  and  performing  tests  of  the  current  build  of  each 
CSCI  to  ensure  that  the  CSCI  requirements  to  be  implemented  in  that  build  have  been  met. 

5.9.1  Independence  in  CSCI  qualification  testing.  The  person(s)  responsible  for  qualification 
testing  of  a  given  CSCI  shall  not  be  the  persons  who  performed  detailed  design  or 
implementation  of  that  CSCI,  This  does  not  preclude  persons  who  performed  detailed  design 
or  implementation  of  the  CSCI  from  contributing  to  the  process,  for  example,  by  contributing 
test  cases  that  rely  on  knowledge  of  the  CSCI's  internal  implementation. 

5.9.2  Testing  on  the  target  computer  system.  CSCI  qualification  testing  shall  include  testing 
on  the  target  computer  system  or  an  alternative  system  approved  by  the  acquirer. 

5.9.3  Preparing  for  CSCI  qualification  testing.  The  developer  shall  define  and  record  the  test 
preparations,  test  cases,  and  test  procedures  to  be  used  for  CSCI  qualification  testing  and  the 
traceability  between  the  test  cases  and  the  CSCI  requirements.  The  result  shall  include  all 
applicable  items  in  the  Software  Test  Description  (STD)  DID  (see  6.2).  The  developer  shall 
prepare  the  test  data  needed  to  carry  out  the  test  cases  and  provide  the  acquirer  advance 
notice  of  the  time  and  location  of  CSCI  qualification  testing. 
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5.9.4  Dry  run  of  CSCI  Qualification  testing.  If  CSCI  qualification  testing  is  to  be  witnessed 
by  the  acquirer,  the  developer  shall  dry  run  the  CSCI  test  cases  and  procedures  to  ensure  that 
they  are  complete  and  accurate  and  that  the  software  is  ready  for  witnessed  testing.  The 
developer  shall  record  the  results  of  this  activity  in  appropriate  software  development  files 
(SDFs)  and  shall  update  the  CSCI  test  cases  and  procedures  as  appropriate. 

5.9.5  Performing  CSCI  Qualification  testing.  The  developer  shall  perform  CSCI  qualification 
testing  of  each  CSCI.  The  testing  shall  be  in  accordance  with  the  CSCI  test  cases  and 
procedures. 

5.9.6  Revision  and  retesting.  The  developer  shall  make  necessary  revisions  to  the  software, 
provide  the  acquirer  advance  notice  of  retesting,  conduct  all  necessary  retesting,  and  update 
the  software  development  files  (SDFs)  and  other  software  products  as  needed,  based  on  the 
results  of  CSCI  qualification  testing. 

5.9.7  Analyzing  and  recording  CSCI  qualification  test  results.  The  developer  shall  analyze 
and  record  the  results  of  CSCI  qualification  testing.  The  results  shall  include  all  applicable 
items  in  the  Software  Test  Report  (STR)  DID  (see  6.2). 

5.10  CSCI/HWCI  integration  and  testing.  The  developer  shall  participate  in  CSCI/HWCI 
integration  and  testing  activities  in  accordance  with  the  following  requirements. 

Note  1 :  CSCI/HWCI  integration  and  testing  means  integrating  CSCls  with  interfacing 
HWCIs  and  CSCls,  testing  the  resulting  groupings  to  determine  whether  they  work 
together  as  intended,  and  continuing  this  process  until  all  CSCls  and  HWCIs  in  the  system 
are  integrated  and  tested.  The  last  stage  of  this  testing  is  developer-internal  system 
testing. 

Note  2:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  CSCI/HWCI  integration  and 
testing  may  not  be  complete  until  the  final  build.  CSCI/HWCI  integration  and  testing  in 
each  build  should  be  interpreted  to  mean  integrating  the  current  build  of  each  CSCI  with 
the  current  build  of  other  CSCls  and  HWCIs  and  testing  the  results  to  ensure  that  the 
system  requirements  to  be  implemented  in  that  build  have  been  met. 

5.10.1  Preparing  for  CSCI/HWCI  integration  and  testing.  The  developer  shall  participate  in 
developing  and  recording  test  cases  (in  terms  of  inputs,  expected  results,  and  evaluation 
criteria),  test  procedures,  and  test  data  for  conducting  CSCI/HWCI  integration  and  testing. 
The  test  cases  shall  cover  all  aspects  of  the  system-wide  and  system  architectural  design. 
The  developer  shall  record  software-related  information  in  appropriate  software  development 
files  (SDFs). 

5.10.2  Performing  CSCI/HWCI  integration  and  testing.  The  developer  shall  participate  in 
CSCI/HWCI  integration  and  testing.  The  testing  shall  be  in  accordance  with  the  CSCI/HWCI 
integration  test  cases  and  procedures. 

5.10.3  Revision  and  retesting.  The  developer  shall  make  necessary  revisions  to  the 
software,  participate  in  all  necessary  retesting,  and  update  the  appropriate  software 
development  files  (SDFs)  and  other  software  products  as  needed,  based  on  the  results  of 
CSCI/HWCI  integration  and  testing. 
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5.10.4  Analyzing  and  recording  CSCI/HWCI  integration  and  test  results.  The  developer  shall 
participate  in  analyzing  the  results  of  CSCI/HWCI  integration  and  testing.  Software-related 
analysis  and  test  results  shall  be  recorded  in  appropriate  software  development  files  (SDFs). 

5.11  System  Qualification  testing.  The  developer  shall  participate  in  system  qualification 
testing  in  accordance  with  the  following  requirements. 

Note  1 :  System  qualification  testing  is  performed  to  demonstrate  to  the  acquirer  that 
system  requirements  have  been  met.  It  covers  the  system  requirements  in  the 
system/subsystem  specifications  (SSSs)  and  in  associated  interface  requirements 
specifications  (IRSs).  This  testing  contrasts  with  developer-internal  system  testing, 
performed  as  the  final  stage  of  CSCI/HWCI  integration  and  testing. 

Note  2:  If  a  system  is  developed  in  multiple  builds,  qualification  testing  of  the  completed 
system  will  not  occur  until  the  final  build.  System  qualification  testing  in  each  build  should 
be  interpreted  to  mean  planning  and  performing  tests  of  the  current  build  of  the  system 
to  ensure  that  the  system  requirements  to  be  implemented  in  that  build  have  been  met. 

5.11.1  Independence  in  system  qualification  testing.  The  person(s)  responsible  for  fulfilling 
the  requirements  in  this  section  shall  not  be  the  persons  who  performed  detailed  design  or 
implementation  of  software  in  the  system.  This  does  not  preclude  persons  who  performed 
detailed  design  or  implementation  of  software  in  the  system  from  contributing  to  the  process, 
for  example,  by  contributing  test  cases  that  rely  on  knowledge  of  the  system's  internal 
implementation. 

5.11.2  Testing  on  the  target  computer  system.  The  developer's  system  qualification  testing 
shall  include  testing  on  the  target  computer  system  or  an  alternative  system  approved  by  the 
acquirer. 

5.1 1 .3  Preparing  for  system  Qualification  testing.  The  developer  shall  participate  in  devel¬ 
oping  and  recording  the  test  preparations,  test  cases,  and  test  procedures  to  be  used  for 
system  qualification  testing  and  the  traceability  between  the  test  cases  and  the  system 
requirements.  For  software  systems,  the  results  shall  include  all  applicable  items  in  the 
Software  Test  Description  (STD)  DID  (see  6.2).  The  developer  shall  participate  in  preparing 
the  test  data  needed  to  carry  out  the  test  cases  and  in  providing  the  acquirer  advance  notice 
of  the  time  and  location  of  system  qualification  testing. 

5.11.4  Dry  run  of  system  Qualification  testing.  If  system  qualification  testing  is  to  be 
witnessed  by  the  acquirer,  the  developer  shall  participate  in  dry  running  the  system  test  cases 
and  procedures  to  ensure  that  they  are  complete  and  accurate  and  that  the  system  is  ready 
for  witnessed  testing.  The  developer  shall  record  the  software-related  results  of  this  activity 
in  appropriate  software  development  files  (SDFs)  and  shall  participate  in  updating  the  system 
test  cases  and  procedures  as  appropriate. 

5.11.5  Performing  system  qualification  testing.  The  developer  shall  participate  in  system 
qualification  testing.  This  participation  shall  be  in  accordance  with  the  system  test  cases  and 
procedures. 

5.11.6  Revision  and  retestina.  The  developer  shall  make  necessary  revisions  to  the 
software,  provide  the  acquirer  advance  notice  of  retesting,  participate  in  all  necessary 
retesting,  and  update  the  software  development  files  (SDFs)  and  other  software  products  as 
needed,  based  on  the  results  of  system  qualification  testing. 
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5.11.7  Analyzing  and  recording  system  qualification  test  results.  The  developer  shall  par¬ 
ticipate  in  analyzing  and  recording  the  results  of  system  qualification  testing.  For  software 
systems,  the  result  shall  include  all  applicable  items  in  the  Software  Test  Report  (STR)  DID 
(see  6.2). 

5.12  Preparing  for  software  use.  The  developer  shall  prepare  for  software  use  in  accor¬ 
dance  with  the  following  requirements. 

Note:  If  software  is  developed  in  multiple  builds,  the  developer's  planning  should  identify 
what  software,  if  any,  is  to  be  fielded  to  users  in  each  build  and  the  extent  of  fielding  (for 
example,  full  fielding  or  fielding  to  selected  evaluators  only).  Preparing  for  software  use 
in  each  build  should  be  interpreted  to  include  those  activities  necessary  to  carry  out  the 
fielding  plans  for  that  build. 

5.12.1  Preparing  the  executable  software.  The  developer  shall  prepare  the  executable  soft¬ 
ware  for  each  user  site,  including  any  batch  files,  command  files,  data  files,  or  other  software 
files  needed  to  install  and  operate  the  software  on  its  target  computer(s).  The  result  shall 
include  all  applicable  items  in  the  executable  software  section  of  the  Software  Product 
Specification  (SPS)  DID,  (see  6.2). 

Note:  To  order  only  the  executable  software  (delaying  delivery  of  source  files  and 
associated  support  information  to  a  later  build),  the  acquirer  can  use  the  SPS  DID,  tailoring 
out  all  but  the  executable  software  section  of  that  DID. 

5.12.2  Preparing  version  descriptions  for  user  sites.  The  developer  shall  identify  and  record 
the  exact  version  of  software  prepared  for  each  user  site.  The  information  shall  include  all 
applicable  items  in  the  Software  Version  Description  (SVD)  DID  (see  6.2). 

5.12.3  Preparing  user  manuals.  The  developer  shall  prepare  user  manuals  in  accordance 
with  the  following  requirements. 

Note:  Few,  if  any,  systems  will  need  all  of  the  manuals  in  this  section.  The  intent  is  for 
the  acquirer,  with  input  from  the  developer,  to  determine  which  manuals  are  appropriate 
for  a  given  system  and  to  require  the  development  of  only  those  manuals.  All  DIDs  permit 
substitution  of  commercial  or  other  manuals  that  contain  the  required  information.  The 
manuals  in  this  section  are  normally  developed  in  parallel  with  software  development, 
ready  for  use  in  CSCI  testing. 

5.1 2.3. 1  Software  user  manuals.  The  developer  shall  identify  and  record  information  needed 
by  hands-on  users  of  the  software  (persons  who  will  both  operate  the  software  and  make  use 
of  its  results).  The  information  shall  include  all  applicable  items  in  the  Software  User  Manual 
(SUM)  DID  (see  6.2). 

5. 1 2.3.2  Software  input/output  manuals.  The  developer  shall  identify  and  record  information 
needed  by  persons  who  will  submit  inputs  to,  and  receive  outputs  from,  the  software,  relying 
on  others  to  operate  the  software  in  a  computer  center  or  other  centralized  or  networked 
software  installation.  The  information  shall  include  all  applicable  items  in  the  Software 
Input/Output  Manual  (SIOM)  DID  (see  6.2). 
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5.1 2.3.3  Software  center  operator  manuals.  The  developer  shall  identify  and  record  infor¬ 
mation  needed  by  persons  who  will  operate  the  software  in  a  computer  center  or  other 
centralized  or  networked  software  installation,  so  that  it  can  be  used  by  others.  The 
information  shall  include  all  applicable  items  in  the  Software  Center  Operator  Manual  (SCOM) 
DID  (see  6.2). 


5.1 2.3.4  Computer  operation  manuals.  The  developer  shall  identify  and  record  information 
needed  to  operate  the  computers  on  which  the  software  will  run.  The  information  shall 
include  all  applicable  items  in  the  Computer  Operation  Manual  (COM)  DID  (see  6.2). 


5.12.4 


The  developer  shall: 


a.  Install  and  check  out  the  executable  software  at  the  user  sites  specified  in  the 
contract. 

b.  Provide  training  to  users  as  specified  in  the  contract. 

c.  Provide  other  assistance  to  user  sites  as  specified  in  the  contract. 


5.13  Preparing  for  software  transition.  The  developer  shall  prepare  for  software  transition 
in  accordance  with  the  following  requirements. 


Note:  If  software  is  developed  in  multiple  builds,  the  developer's  planning  should  identify 
what  software,  if  any,  is  to  be  transitioned  to  the  support  agency  in  each  build.  Preparing 
for  software  transition  in  each  build  should  be  interpreted  to  include  those  activities 
necessary  to  carry  out  the  transition  plans  for  that  build. 


513.1  Preparing  the  executable  software.  The  developer  shall  prepare  the  executable  soft¬ 
ware  to  be  transitioned  to  the  support  site,  including  any  batch  files,  command  files,  data 
files,  or  other  software  files  needed  to  install  and  operate  the  software  on  its  target 
computer(s).  The  result  shall  include  all  applicable  items  in  the  executable  software  section 
of  the  Software  Product  Specification  (SPS)  DID  (see  6.2). 


5.1 3.2  Preparing  source  files.  The  developer  shall  prepare  the  source  files  to  be  transitioned 
to  the  support  site,  including  any  batch  files,  command  files,  data  files,  or  other  files  needed 
to  regenerate  the  executable  software.  The  result  shall  include  all  applicable  items  in  the 
source  file  section  of  the  Software  Product  Specification  (SPS)  DID  (see  6.2). 


5.13.3  Preparing  version  descriptions  for  the  support  site.  The  developer  shall  identify  and 
record  the  exact  version  of  software  prepared  for  the  support  site.  The  information  shall 
include  all  applicable  items  in  the  Software  Version  Description  (SVD)  DID  (see  6.2). 


5-13.4  Preparing  the  ”as  built"  CSCI  design  and  related  information.  The  developer  shall 
update  the  design  description  of  each  CSCI  to  match  the  "as  built"  software  and  shall  define 
and  record:  the  methods  to  be  used  to  verify  copies  of  the  software,  the  measured  computer 
hardware  resource  utilization  for  the  CSCI,  other  information  needed  to  support  the  software, 
and  traceability  between  the  CSCI's  source  files  and  software  units  and  between  the 
computer  hardware  resource  utilization  measurements  and  the  CSCI  requirements  concerning 
them.  The  result  shall  include  all  applicable  items  in  the  qualification,  software  support,  and 
traceability  sections  of  the  Software  Product  Specification  (SPS)  DID  (see  6.2). 
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Note:  In  hardware  development,  the  final  product  is  an  approved  design  from  which 
hardware  items  can  be  manufactured.  This  design  is  presented  in  the  product 
specification.  In  software  development,  by  contrast,  the  final  product  is  the  software,  not 
its  design,  and  "manufacturing"  consists  of  electronically  duplicating  the  software,  not 
recreating  it  from  the  design.  The  "as  built"  design  is  included  in  the  software  product 
specification  not  as  the  product  but  as  information  that  may  help  the  support  agency 
understand  the  software  in  order  to  modify,  enhance,  and  otherwise  support  it. 

5.13.5  Updating  the  system  design  description.  The  developer  shall  participate  in  updating 
the  system  design  description  to  match  the  "as  built"  system.  The  result  shall  include  all 
applicable  items  in  the  System/Subsystem  Design  Description  (SSDD)  DID  (see  6.2). 

5.13.6  Preparing  support  manuals.  The  developer  shall  prepare  support  manuals  in  accor¬ 
dance  with  the  following  requirements. 

Note:  Not  all  systems  will  need  the  manuals  in  this  section.  The  intent  is  for  the  acquirer, 
with  input  from  the  developer,  to  determine  which  manuals  are  appropriate  for  a  given 
system  and  to  require  the  development  of  only  those  manuals.  All  DIDs  permit  substitution 
of  commercial  or  other  manuals  that  contain  the  required  information.  The  manuals  in  this 
section  supplement  the  system/subsystem  design  description  (SSDD)  and  the  software 
product  specifications  (SPSs),  which  serve  as  the  primary  sources  of  information  for 
software  support.  The  user  manuals  cited  in  5.1 2.3  are  also  useful  to  support  personnel. 

5.13.6.1  Computer  programming  manuals.  The  developer  shall  identify  and  record  infor¬ 
mation  needed  to  program  the  computers  on  which  the  software  was  developed  or  on  which 
it  will  run.  The  information  shall  include  all  applicable  items  in  the  Computer  Programming 
Manual  (CPM)  DID  (see  6.2). 

5.13.6.2  Firmware  support  manuals.  The  developer  shall  identify  and  record  information 
needed  to  program  and  reprogram  any  firmware  devices  in  which  the  software  will  be 
installed.  The  information  shall  include  all  applicable  items  in  the  Firmware  Support  Manual 
(FSM)  DID  (see  6.2). 

5.13.7  Transition  to  the  designated  support  site.  The  developer  shall: 

a.  Install  and  check  out  the  deliverable  software  in  the  support  environment  designated 
in  the  contract. 

b.  Demonstrate  to  the  acquirer  that  the  deliverable  software  can  be  regenerated 
(compiled/linked/loaded  into  an  executable  product)  and  maintained  using  commercially 
available,  acquirer-owned,  or  contractually  deliverable  software  and  hardware 
designated  in  the  contract  or  approved  by  the  acquirer. 

c.  Provide  training  to  the  support  agency  as  specified  in  the  contract. 

d.  Provide  other  assistance  to  the  support  agency  as  specified  in  the  contract. 
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5.14  Software  configuration  management.  The  developer  shall  perform  software  config¬ 
uration  management  in  accordance  with  the  following  requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  the  software  products  of  each 
build  may  be  refinements  of,  or  additions  to,  software  products  of  previous  builds. 
Software  configuration  management  in  each  build  should  be  understood  to  take  place  in 
the  context  of  the  software  products  and  controls  in  place  at  the  start  of  the  build. 

5.14.1  Configuration  identification.  The  developer  shall  participate  in  selecting  CSCIs,  as 
performed  under  system  architectural  design  in  5.4.2,  shall  identify  the  entities  to  be  placed 
under  configuration  control,  and  shall  assign  a  project-unique  identifier  to  each  CSCI  and  each 
additional  entity  to  be  placed  under  configuration  control.  These  entities  shall  include  the 
software  products  to  be  developed  or  used  under  the  contract  and  the  elements  of  the 
software  development  environment.  The  identification  scheme  shall  be  at  the  level  at  which 
entities  will  actually  be  controlled,  for  example,  computer  files,  electronic  media,  documents, 
software  units,  configuration  items.  The  identification  scheme  shall  include  the  version/ 
revision/release  status  of  each  entity. 

5.14.2  Configuration  control.  The  developer  shall  establish  and  implement  procedures 
designating  the  levels  of  control  each  identified  entity  must  pass  through  (for  example,  author 
control,  project-level  control,  acquirer  control);  the  persons  or  groups  with  authority  to 
authorize  changes  and  to  make  changes  at  each  level  (for  example,  the  programmer/analyst, 
the  software  lead,  the  project  manager,  the  acquirer);  and  the  steps  to  be  followed  to  request 
authorization  for  changes,  process  change  requests,  track  changes,  distribute  changes,  and 
maintain  past  versions.  Changes  that  affect  an  entity  already  under  acquirer  control  shall  be 
proposed  to  the  acquirer  in  accordance  with  contractually  established  forms  and  procedures, 
if  any. 

Note:  A  number  of  requirements  in  this  standard  refer  to  "project-level  or  higher 
configuration  control."  If  "project-level"  is  not  a  level  of  control  selected  for  the  project, 
the  software  development  plan  should  state  how  these  requirements  map  to  the  selected 
levels. 

5.14.3  Configuration  status  accounting.  The  developer  shall  prepare  and  maintain  records 
of  the  configuration  status  of  all  entities  that  have  been  placed  under  project-level  or  higher 
configuration  control.  These  records  shall  be  maintained  for  the  life  of  the  contract.  They 
shall  include,  as  applicable,  the  current  version/revision/release  of  each  entity,  a  record  of 
changes  to  the  entity  since  being  placed  under  project-level  or  higher  configuration  control, 
and  the  status  of  problem/change  reports  affecting  the  entity. 

5.14.4  Configuration  audits.  The  developer  shall  support  acquirer-conducted  configuration 
audits  as  specified  in  the  contract. 

Note:  These  configuration  audits  may  be  called  Functional  Configuration  Audits  and 
Physical  Configuration  Audits. 

5.14.5  Packaging,  storage,  handling,  and  delivery.  The  developer  shall  establish  and 
implement  procedures  for  the  packaging,  storage,  handling,  and  delivery  of  deliverable 
software  products.  The  developer  shall  maintain  master  copies  of  delivered  software  products 
for  the  duration  of  the  contract. 
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5.15  Software  product  evaluation.  The  developer  shall  perform  software  product  evaluation 
in  accordance  with  the  following  requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  the  software  products  of  each 
build  should  be  evaluated  in  the  context  of  the  objectives  established  for  that  build.  A 
software  product  that  meets  those  objectives  can  be  considered  satisfactory  even  though 
it  is  missing  information  designated  for  development  in  later  builds. 

5.15.1  In-process  and  final  software  product  evaluations.  The  developer  shall  perform  in- 
process  evaluations  of  the  software  products  generated  in  carrying  out  the  requirements  of 
this  standard.  In  addition,  the  developer  shall  perform  a  final  evaluation  of  each  deliverable 
software  product  before  its  delivery.  The  software  products  to  be  evaluated,  criteria  to  be 
used,  and  definitions  for  those  criteria  are  given  in  Appendix  D. 

5.15.2  Software  product  evaluation  records.  The  developer  shall  prepare  and  maintain 
records  of  each  software  product  evaluation.  These  records  shall  be  maintained  for  the  life 
of  the  contract.  Problems  in  software  products  under  project-level  or  higher  configuration 
control  shall  be  handled  as  described  in  5.17  (Corrective  action). 

5.15.3  Independence  in  software  product  evaluation.  The  persons  responsible  for  evaluating 
a  software  product  shall  not  be  the  persons  who  developed  the  product.  This  does  not 
preclude  the  persons  who  developed  the  software  product  from  taking  part  in  the  evaluation 
(for  example,  as  participants  in  a  walk-through  of  the  product). 

5.16  Software  quality  assurance.  The  developer  shall  perform  software  quality  assurance 
in  accordance  with  the  following  requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  the  activities  and  software 
products  of  each  build  should  be  evaluated  in  the  context  of  the  objectives  established  for 
that  build.  An  activity  or  software  product  that  meets  those  objectives  can  be  considered 
satisfactory  even  though  it  is  missing  aspects  designated  for  later  builds.  Planning  for 
software  quality  assurance  is  included  in  software  development  planning  (see  5.1.1). 

5.16.1  Software  quality  assurance  evaluations.  The  developer  shall  conduct  on-going 
evaluations  of  software  development  activities  and  the  resulting  software  products  to: 

a.  Assure  that  each  activity  required  by  the  contract  or  described  in  the  software 
development  plan  is  being  performed  in  accordance  with  the  contract  and  with  the 
software  development  plan. 

b.  Assure  that  each  software  product  required  by  this  standard  or  by  other  contract 
provisions  exists  and  has  undergone  software  product  evaluations,  testing,  and 
corrective  action  as  required  by  this  standard  and  by  other  contract  provisions. 

5.16.2  Software  quality  assurance  records.  The  developer  shall  prepare  and  maintain 
records  of  each  software  quality  assurance  activity.  These  records  shall  be  maintained  for  the 
life  of  the  contract.  Problems  in  software  products  under  project-level  or  higher  configuration 
control  and  problems  in  activities  required  by  the  contract  or  described  in  the  software 
development  plan  shall  be  handled  as  described  in  5.17  (Corrective  action). 
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5.16.3  Independence  in  software  quality  assurance.  The  persons  responsible  for  conducting 
software  quality  assurance  evaluations  shall  not  be  the  persons  who  developed  the  software 
product,  performed  the  activity,  or  are  responsible  for  the  software  product  or  activity.  This 
does  not  preclude  such  persons  from  taking  part  in  these  evaluations.  The  persons 
responsible  for  assuring  compliance  with  the  contract  shall  have  the  resources,  responsibility, 
authority,  and  organizational  freedom  to  permit  objective  software  quality  assurance 
evaluations  and  to  initiate  and  verify  corrective  actions. 

5.17  Corrective  action.  The  developer  shall  perform  corrective  action  in  accordance  with 
the  following  requirements. 

5.17.1  Problem/chanoe  reports.  The  developer  shall  prepare  a  problem/change  report  to 
describe  each  problem  detected  in  software  products  under  project-level  or  higher 
configuration  control  and  each  problem  in  activities  required  by  the  contract  or  described  in 
the  software  development  plan.  The  problem/change  report  shall  describe  the  problem,  the 
corrective  action  needed,  and  the  actions  taken  to  date.  These  reports  shall  serve  as  input 
to  the  corrective  action  system. 

5.17.2  Corrective  action  system.  The  developer  shall  implement  a  corrective  action  system 
for  handling  each  problem  detected  in  software  products  under  project-level  or  higher 
configuration  control  and  each  problem  in  activities  required  by  the  contract  or  described  in 
the  software  development  plan.  The  system  shall  meet  the  following  requirements: 

a.  Inputs  to  the  system  shall  consist  of  problem/change  reports. 

b.  The  system  shall  be  closed-loop,  ensuring  that  all  detected  problems  are  promptly 
reported  and  entered  into  the  system,  action  is  initiated  on  them,  resolution  is 
achieved,  status  is  tracked,  and  records  of  the  problems  are  maintained  for  the  life  of 
the  contract. 

c.  Each  problem  shall  be  classified  by  category  and  priority,  using  the  categories  and 
priorities  in  Appendix  C  or  approved  alternatives. 

d.  Analysis  shall  be  performed  to  detect  trends  in  the  problems  reported. 

e.  Corrective  actions  shall  be  evaluated  to  determine  whether  problems  have  been 
resolved,  adverse  trends  have  been  reversed,  and  changes  have  been  correctly 
implemented  without  introducing  additional  problems. 

5.18  Joint  technical  and  management  reviews.  The  developer  shall  plan  and  take  part  in 
joint  (acquirer/developer)  technical  and  management  reviews  in  accordance  with  the  following 
requirements. 

Note:  If  a  system  or  CSCI  is  developed  in  multiple  builds,  the  types  of  joint  reviews  held 
and  the  criteria  applied  will  depend  on  the  objectives  of  each  build.  Software  products  that 
meet  those  objectives  can  be  considered  satisfactory  even  though  they  are  missing 
information  designated  for  development  in  later  builds. 
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5.18.1  Joint  technical  reviews.  The  developer  shall  plan  and  take  part  in  joint  technical 
reviews  at  locations  and  dates  proposed  by  the  developer  and  approved  by  the  acquirer. 
These  reviews  shall  be  attended  by  persons  with  technical  knowledge  of  the  software 
products  to  be  reviewed.  The  reviews  shall  focus  on  in-process  and  final  software  products, 
rather  than  materials  generated  especially  for  the  review.  The  reviews  shall  have  the 
following  objectives: 

a.  Review  evolving  software  products,  using  as  criteria  the  software  product  evaluation 
criteria  in  Appendix  D;  review  and  demonstrate  proposed  technical  solutions;  provide 
insight  and  obtain  feedback  on  the  technical  effort;  surface  and  resolve  technical 
issues. 

b.  Review  project  status;  surface  near-  and  long-term  risks  regarding  technical,  cost,  and 
schedule  issues. 

c.  Arrive  at  agreed-upon  mitigation  strategies  for  identified  risks,  within  the  authority  of 
those  present. 

d.  Identify  risks  and  issues  to  be  raised  at  joint  management  reviews. 

e.  Ensure  on-going  communication  between  acquirer  and  developer  technical  personnel. 

5.18.2  Joint  management  reviews.  The  developer  shall  plan  and  take  part  in  joint 
management  reviews  at  locations  and  dates  proposed  by  the  developer  and  approved  by  the 
acquirer.  These  reviews  shall  be  attended  by  persons  with  authority  to  make  cost  and 
schedule  decisions  and  shall  have  the  following  objectives.  Examples  of  such  reviews  are 
identified  in  Appendix  E. 

a.  Keep  management  informed  about  project  status,  directions  being  taken,  technical 
agreements  reached,  and  overall  status  of  evolving  software  products. 

b.  Resolve  issues  that  could  not  be  resolved  at  joint  technical  reviews. 

c.  Arrive  at  agreed-upon  mitigation  strategies  for  near-  and  long-term  risks  that  could  not 
be  resolved  at  joint  technical  reviews. 

d.  Identify  and  resolve  management-level  issues  and  risks  not  raised  at  joint  technical 
reviews. 

e.  Obtain  commitments  and  acquirer  approvals  needed  for  timely  accomplishment  of  the 
project. 

5.19  Other  activities.  The  developer  shall  perform  the  following  activities. 

5.19.1  Risk  management.  The  developer  shall  perform  risk  management  throughout  the 
software  development  process.  The  developer  shall  identify,  analyze,  and  prioritize  the  areas 
of  the  software  development  project  that  involve  potential  technical,  cost,  or  schedule  risks; 
develop  strategies  for  managing  those  risks;  record  the  risks  and  strategies  in  the  software 
development  plan;  and  implement  the  strategies  in  accordance  with  the  plan. 
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5.19.2  Software  management  indicators.  The  developer  shall  use  software  management 
indicators  to  aid  in  managing  the  software  development  process  and  communicating  its  status 
to  the  acquirer.  The  developer  shall  identify  and  define  a  set  of  software  management 
indicators,  including  the  data  to  be  collected,  the  methods  to  be  used  to  interpret  and  apply 
the  data,  and  the  planned  reporting  mechanism.  The  developer  shall  record  this  information 
in  the  software  development  plan  and  shall  collect,  interpret,  apply,  and  report  on  those 
indicators  as  described  in  the  plan.  Candidate  indicators  are  given  in  Appendix  F. 

5.19.3  Security  and  privacy.  The  developer  shall  meet  the  security  and  privacy  requirements 
specified  in  the  contract.  These  requirements  may  affect  the  software  development  effort, 
the  resulting  software  products,  or  both. 

5.1 9.4  Subcontractor  rnsnaaement.  If  subcontractors  are  used,  the  developer  shall  include 
in  subcontracts  all  contractual  requirements  necessary  to  ensure  that  software  products  are 
developed  in  accordance  with  prime  contract  requirements. 

5.19.5  Interface  with  software  IV&V  agents.  The  developer  shall  interface  with  the 
software  Independent  Verification  and  Validation  (IV&V)  agent(s)  as  specified  in  the  contract. 

5.19.6  Coordination  with  associate  developers.  The  developer  shall  coordinate  with 
associate  developers,  working  groups,  and  interface  groups  as  specified  in  the  contract. 

5.19.7  Improvement  of  project  processes.  The  developer  shall  periodically  assess  the 
processes  used  on  the  project  to  determine  their  suitability  and  effectiveness.  Based  on  these 
assessments,  the  developer  shall  identify  any  necessary  and  beneficial  improvements  to  the 
process,  shall  identify  these  improvements  to  the  acquirer  in  the  form  of  proposed  updates 
to  the  software  development  plan  and,  if  approved,  shall  implement  the  improvements  on  the 
project. 
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6.  NOTES 

(This  section  contains  information  of  a  general  or  explanatory  nature  that  may  be 
helpful,  but  is  not  mandatory.) 

6.1  Intended  use.  This  standard  contains  requirements  for  the  development  and 
documentation  of  software.  Its  application  is  described  in  1.2. 

6.2  Data  requirements.  The  following  Data  Item  Descriptions  (DIDs)  must  be  listed,  as 
applicable,  on  the  Contract  Data  Requirements  List  (DD  Form  1423)  when  this  standard  is 
applied  on  a  contract,  in  order  to  obtain  the  data,  except  where  DOD  FAR  Supplement 
227.405-70  exempts  the  requirement  for  a  DD  Form  1423. 


Reference  Para 

DID  Number 

DID  Title 

5.1.1 

DI-IPSC-81427 

Software  Development  Plan  (SDP) 

5.1.2,  5.1.3 

DI-IPSC-81438 

Software  Test  Plan  (STP) 

5.1.4 

DI-IPSC-81428 

Software  Installation  Plan  (SIP) 

5.1.5 

DI-IPSC-81429 

Software  Transition  Plan  (STrP) 

5.3.2 

DI-IPSC-81430 

Operational  Concept  Description  (OCD) 

5.3.3 

DI-IPSC-81431 

System/Subsystem  Specification  (SSS) 

5.3.3,  5.5 

DI-IPSC-81434 

interface  Requirements  Specification  (IRS) 

5.4.1,  5.4.2,  5.13.5 

DI-IPSC-81432 

System/Subsystem  Design  Description  (SSDD) 

5.4.1,  5.4.2,  5.6.1, 

5.6.2,  5.6.3 

DI-IPSC-81436 

Interface  Design  Description  HDD) 

5.5 

DI-IPSC-81433 

Software  Requirements  Specification  (SRS) 

5.6.1,  5.6.2,  5.6.3 

DI-IPSC-81435 

Software  Design  Description  (SDD) 

5.4.1,  5.6.1,  5.6.3 

DI-IPSC-81437 

Database  Design  Description  (DBDD) 

5.9.3,  5.11.3 

DI-IPSC-81 439 

Software  Test  Description  (STD) 

5.9.7,  5.11.7 

DI-IPSC-81440 

Software  Test  Report  (STR) 

5.12.1,5.13.1,5.13.2, 

5.13.4 

DI-IPSC-81 441 

Software  Product  Specification  (SPS) 

5.12.2,  5.13.3 

DI-IPSC-81 442 

Software  Version  Description  (SVD) 

5.12.3.1 

DI-IPSC-81 443 

Software  User  Manual  (SUM) 

5.12.3.2 

DI-IPSC-81 445 

Software  Input/Output  Manual  (SIOM) 

5.12.3.3 

DI-IPSC-81 444 

Software  Center  Operator  Manual  (SCOM) 

5.12.3.4 

DI-IPSC-81 446 

Computer  Operation  Manual  (COM) 

5.13.6.1 

DI-IPSC-81 447 

Computer  Programming  Manual  (CPM) 

5.13.6.2 

DI-IPSC-81 448 

Firmware  Support  Manual  (FSM) 

The  above  DIDs  were  those  cleared  as  of  the  date  of  this  standard.  The  current  issue  of  DOD 
5010.12,  Acquisition  Management  Systems  and  Data  Requirements  Control  List  (AMSDL), 
must  be  researched  to  ensure  that  only  current,  cleared  DIDs  are  cited  on  the  Form  1423. 
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6.3  Relationship  between  standard  and  CDRL.  If  the  CDRL  calls  for  a  DID  different  from 
the  one  named  in  corresponding  paragraph(s)  of  this  standard,  all  references  to  the  DID  in  the 
standard  should  be  interpreted  to  mean  the  one  in  the  CDRL. 

6.4  Delivery  of  tool  contents.  Depending  on  contract  provisions,  the  developer  may  be 
permitted  to  satisfy  CDRL  requirements  by  delivering:  1 )  a  repository  or  database  containing 
the  information  specified  in  the  cited  DID;  2)  a  means  of  accessing  that  repository  or 
database,  such  as  a  CASE  tool,  if  not  already  available  to  the  recipients  designated  on  the 
CDRL;  and  3)  a  hard-copy  or  electronically  stored  table  of  contents,  specifying  how  and  where 
to  access  the  information  required  in  each  paragraph  of  the  DID. 

6.5  Tailoring  guidance.  This  standard  and  its  Data  Item  Descriptions  (DIDs)  are  applied  at 
the  discretion  of  the  acquirer.  In  each  application,  the  standard  and  DIDs  should  be  tailored 
to  the  specific  requirements  of  a  particular  program,  program  phase,  or  contractual  structure. 
Care  should  be  taken  to  eliminate  tasks  that  add  unnecessary  costs  and  data  that  do  not  add 
value  to  the  process  or  the  product.  Tailoring  for  the  standard  takes  the  form  of  deletion  of 
activities,  alteration  of  activities  to  more  explicitly  reflect  the  application  to  a  particular  effort, 
or  addition  of  activities  to  satisfy  program  requirements.  This  tailoring  is  specified  in  the 
Statement  of  Work.  Tailoring  for  the  DIDs  consists  of  deleting  requirements  for  unneeded 
information  and  making  other  changes,  such  as  combining  two  documents  under  one  cover, 
that  do  not  increase  the  required  workload.  DID  tailoring  for  deliverables  is  specified  in  Block 
1 6  of  the  CDRL. 

6.6  Cost/schedule  reporting.  Developer  cost/schedule  reports  should  be  prepared  at  the 
CSCI  level.  The  cost  reports  should  indicate  budgeted  versus  actual  expenditures  and  should 
conform  to  the  Work  Breakdown  Structure  (WBS)  applicable  to  the  development  effort.  These 
reports  should  also  indicate  to  the  acquirer  planned,  actual,  and  predicted  progress. 

6.7  Related  standardization  documents.  Figure  2  identifies  a  set  of  standardization 
documents  related  to  software  development.  These  and  other  standardization  documents  may 
be  imposed  or  quoted  in  the  Statement  of  Work  to  supplement  the  requirements  in  MIL-STD- 
498.  MIL-STD-498  does  not  invoke  these  documents.  The  acquirer  should  use  caution  to 
ensure  that  supplemental  standards  are  appropriate  to  the  project  and  that  any  conflicts 
among  these  standards  or  with  MIL-STD-498  are  identified  and  resolved. 

6.8  Subject  term  (kev  word)  listing.  The  following  list  of  key  words  may  be  used  to  catalog 
or  characterize  key  topics  in  this  standard. 


Builds/incremental  development 
Computer  software  configuration  item 
Database 

Joint  technical/management  reviews 

Operational  concept 

Reusable  software 

Risk  management 

Security/privacy 

Software 

Software  configuration  management 
Software  development 


Software  documentation 
Software  implementation 
Software  management  indicators 
Software  product  evaluation 
Software  quality  assurance 
Software  requirements  analysis 
Software  safety 
Software  support 
Software  testing 
Software  unit 
Tailoring 
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Topic  and 

MIL-STD-498  Paragraph 

Related  Standardization  Documents 
(Determine  latest  version  before  use) 

Behavioral  design 
(5.4.1,  5.6.1) 

MIL-STD-1 801,  User  Computer  Interface 

MIL-HDBK-761 ,  Human  Engineering  Guidelines  for  Management  Information 
Systems 

Computer  security 
(4.2.4.21 

DOD-5200.28  STD,  DoD  Trusted  Computer  System  Evaluation  Criteria 

Configuration  management 
(5.14) 

ANSI/IEEE  Std  828,  Standard  for  Software  Configuration 

Management  Plans 

ANSI/IEEE  Std  1042,  Guide  to  Software  Configuration  Management 
MIL-STD-973,  Configuration  Management 

MIL-HDBK-61  Guidelines  for  Configuration  Management 

Continuous  acquisition  and 
life-cycle  support  (CALS) 

MIL-STD-1 840,  Automated  Interchange  of  Technical  Information 

MIL-STD-1 556,  Government-Industry  Data  Exchange  Program 

MIL-HDBK-59,  Continuous  Acquisition  and  Life-Cycle  Support  Program 
Implementation  Guide 

MIL-HDBK-800,  Documentation  Streamlining 

MIL-D-28000,  Digital  Representation  for  Communication  of  Product  Data: 

IGES  Application  Subset  and  IGES  Application  Protocols 

MIL-M-28001,  Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  Text 

MIL-R-28002,  Requirements  for  Raster  Graphics  Representation  in  Binary 
Format 

MIL-D-28003,  Digital  Representation  for  Communication  of  Illustration  Data: 
CGM  Application  Profile 

Joint  technical  and 
management  reviews 
(5.18,  App.  E) 

ANSI/IEEE  Std  1028,  Standard  for  Software  Reviews  and  Audits 

MIL-STD-499,  Engineering  Management 

MIL-STD-1 521 ,  Technical  Reviews  and  Audits  for  Systems,  Equipments, 
and  Computer  Software  (audit  portion  superseded  by  MIL-STD-973) 

Programming  languages 
(5.7.1) 

FIPS-PUB-1 1 9,  Ada  (Also  issued  as  ANSI/ISO/IEC  8652; 

formerly  ANSI/MIL-STD-1815,  Ada  Programming  Language) 

Software  design 
(5.4,  5.6) 

ANSI/IEEE  Std  1016,  Recommended  Practice  for  Software  Design 

Descriptions 

IEEE  Std  1016.1,  Guide  for  Software  Design  Descriptions 

IEEE/ANSI  Std  990,  Recommended  Practice  for  Ada  as  a  Program 

Design  Language 

Software  development 

environment 

(5.2) 

IEEE  Std  1209,  Recommended  Practice  for  the  Evaluation  and 

Selection  of  CASE  Tools 

DOD-STD-1467  (AR),  Software  Support  Environment 

MIL-HDBK-782  (AR),  Software  Support  Environment  Acquisition 

Software  development 
planning  (5.1.1) 

ANSI/IEEE  Std  1058.1,  Standard  for  Software  Project  Management 

Plans 

Software  development 

process 

(4.1,  App.  G) 

ISO/IEC  1 2207  (when  issued),  Software  Life-Cycle  Processes 

ANSI/IEEE  Std  1074,  Standard  for  Developing  Software  Life 

Cycle  Processes 

MIL-STD-1 803  (USAF),  Software  Development  Integrity  Program 

Guidebook  on  MIL-STD-498  (when  issued) 

MIL-HDBK-498  (when  issued) 

Note:  MIL-STD-498  does  not  invoke  any  of  these  documents. 


FIGURE  2.  Related  standardization  documents. 
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Topic  and 

MIL-STD-498  Paragraph 

Related  Standardization  Documents 
(Determine  latest  version  before  use) 

Software  management 

indicators 

(5.19.2,  App.  F) 

ISO/IEC  9126,  Quality  Characteristics  and  Guidelines  for  Their  Use 

ANSI/IEEE  Std  982.2,  Guide:  Use  of  Standard  Measures  to  Produce 

Reliable  Software 

IEEE  Std  1045,  Standard  for  Software  Productivity  Metrics 

IEEE  Std  1061,  Standard  for  Software  Quality  Metrics  Methodology 

Software  problem 
categories/priorities 
(Appendix  C) 

IEEE  Std  1044,  Standard  Classification  for  Software  Anomalies 

Software  product 
evaluation  (5.15) 

ANSI/IEEE  Std  1012,  Standard  for  Software  Verification 
and  Validation  Plans 

IEEE  Std  1059,  Guide  for  Verification  and  Validation  Plans 

Software  quality 

assurance 

(5.16) 

ISO  9001,  Quality  System  -  Model  for  Quality  Assurance  in 
Design/Development,  Production,  Installation,  and  Servicing 

ISO  9000-3,  Guidelines  for  the  Application  of  ISO  9001  to  the  Development, 
Supply,  and  Maintenance  of  Software 

ANSI/IEEE  Std  730,  Standard  for  Software  Quality  Assurance  Plans 

IEEE  Std  1 298/A3563.1 ,  Software  Quality  Management  System 
DOD-STD-2168,  Defense  System  Software  Quality  Program 

MIL-HDBK-286,  A  Guide  for  DOD-STD-2168 

Software  requirements 
(5.3.3,  5.5) 

ANSI/IEEE  Std  830,  Recommended  Practice  for  Software 

Requirements  Specifications 

MIL-STD-490,  Specification  Practices 

Software  safety  (4. 2. 4.1) 

MIL-STD-882,  System  Safety  Program  Requirements 

MIL-HDBK-272,  Safety  Design  and  Evaluation  Criteria  for  Nuclear  Weapons 
Systems 

IEEE  Std  1228,  Standard  for  Software  Safety  Plans 

Software  support 
(all  paragraphs) 

IEEE  Std  1219,  Standard  for  Software  Maintenance 

MIL-HDBK-347,  Mission-Critical  Computer  Resources  Software  Support 

Software  testing 
(5.1.2,  5.1.3, 

5.7  -  5.11) 

ANSI/IEEE  Std  829,  Standard  for  Software  Test  Documentation 

ANSI/IEEE  Std  1008,  Standard  for  Software  Unit  Testing 

ANSI/IEEE  Std  1012,  Standard  for  Software  Verification 
and  Validation  Plans 

IEEE  Std  1059,  Guide  for  Verification  and  Validation  Plans 

Software  user 
documentation  (5.12.3) 

ANSI/IEEE  Std  1063,  Standard  for  Software  User  Documentation 

Systems  engineering 
(5.1.3,  5.3,  5.4,  5.10, 

5.11) 

MIL-STD-499,  Engineering  Management 

Mll-HDBK-805,  Microcomputer  Software  and  Hardware  Guidelines 

Tailoring 
(1.2.3,  6.5, 

App.  G,  H 

DOD-HDBK-248,  Guide  for  Application  and  Tailoring  of  Requirements  for 
Defense  Materiel  Acquisitions 

MIL-HDBK-498  (when  issued) 

Training  (5.12.4,  5.13.7) 

MIL-STD-1 379,  Military  Training  Programs 

Work  breakdown  structure 
(6.6) 

MIL-STD-881,  Work  Breakdown  Structures  for  Defense  Materiel  Items 

Note:  MIL-STD-498  does  not  invoke  any  of  these  documents. 


FIGURE  2.  Related  standardization  documents  -  continued. 
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APPENDIX  A 
LIST  OF  ACRONYMS 


A.1  Scope.  This  appendix  provides  a  list  of  acronyms  used  in  this  standard,  with  their 
associated  meanings.  This  appendix  is  not  a  mandatory  part  of  the  standard.  The  information 
provided  is  intended  for  guidance  only. 

A. 2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

A. 3  Acronyms. 


CASE  Computer-Aided  Software  Engineering 

CDRL  Contract  Data  Requirements  List 

COM  Computer  Operation  Manual 

CPM  Computer  Programming  Manual 

CSCI  Computer  Software  Configuration  Item 

DBDD  Database  Design  Description 

DID  Data  Item  Description 

DoD  Department  of  Defense 

FSM  Firmware  Support  Manual 

HWCI  Hardware  Configuration  Item 

IDD  Interface  Design  Description 

IRS  Interface  Requirements  Specification 

IV&V  Independent  Verification  and  Validation 

OCD  Operational  Concept  Description 

SCOM  Software  Center  Operator  Manual 

SDD  Software  Design  Description 

SDF  Software  Development  File 

SDL  Software  Development  Library 

SDP  Software  Development  Plan 

SIOM  Software  Input/Output  Manual 

SIP  Software  Installation  Plan 

SOW  Statement  of  Work 

SPS  Software  Product  Specification 

SRS  Software  Requirements  Specification 

SSDD  System/Subsystem  Design  Description 

SSS  System/Subsystem  Specification 

STD  Software  Test  Description 

STP  Software  Test  Plan 

STR  Software  Test  Report  ' 

STrP  Software  Transition  Plan 

SUM  Software  User  Manual 

SVD  Software  Version  Description 

SW  Software 

WBS  <||  Work  Breakdown  Structure 
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APPENDIX  B 

INTERPRETING  MIL-STD-498  FOR  INCORPORATION  OF  REUSABLE  SOFTWARE  PRODUCTS 

B.1  Scope.  This  appendix  interprets  MIL-STD-498  when  applied  to  the  incorporation  of 
reusable  software  products.  This  appendix  is  a  mandatory  part  of  this  standard,  subject  to 
tailoring  by  the  acquirer. 

B.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

B.3  Evaluating  reusable  software  products.  The  developer  shall  specify  in  the  software 
development  plan  the  criteria  to  be  used  for  evaluating  reusable  software  products  for  use  in 
fulfilling  the  requirements  of  the  contract.  General  criteria  shall  be  the  software  product's 
ability  to  meet  specified  requirements  and  to  be  cost-effective  over  the  life  of  the  system. 
Non-mandatory  examples  of  specific  criteria  include,  but  are  not  limited  to: 

a.  Ability  to  provide  required  capabilities  and  meet  required  constraints 

b.  Ability  to  provide  required  safety,  security,  and  privacy 

c.  Reliability/maturity,  as  evidenced  by  established  track  record 

d.  Testability 

e.  Interoperability  with  other  system  and  system-external  elements 

f.  Fielding  issues,  including: 

1 )  Restrictions  on  copying/distributing  the  software  or  documentation 

2)  License  or  other  fees  applicable  to  each  copy 

g.  Maintainability,  including: 

1)  Likelihood  the  software  product  will  need  to  be  changed 

2)  Feasibility  of  accomplishing  that  change 

3)  Availability  and  quality  of  documentation  and  source  files 

4)  Likelihood  that  the  current  version  will  continue  to  be  supported  by  the  supplier 

5)  Impact  on  the  system  if  the  current  version  is  not  supported 

6)  The  acquirer's  data  rights  to  the  software  product 

7)  Warranties  available 

h.  Short-  and  long-term  cost  impacts  of  using  the  software  product 

i.  Technical,  cost,  and  schedule  risks  and  tradeoffs  in  using  the  software  product 

B.4  Interpreting  MIL-STD-498  activities  for  reusable  software  products.  The  following 
rules  apply  in  interpreting  this  standard: 

a.  Any  requirement  that  calls  for  development  of  a  software  product  may  be  met  by  a 
reusable  software  product  that  fulfills  the  requirement  and  meets  the  criteria 
established  in  the  software  development  plan.  The  reusable  software  product  may  be 
used  as-is  or  modified  and  may  be  used  to  satisfy  part  or  all  of  the  requirement.  For 
example,  a  requirement  may  be  met  by  using  an  existing  plan,  specification,  or  design. 

b.  When  the  reusable  software  product  to  be  incorporated  is  the  software  itself,  some 
of  the  requirements  in  this  standard  require  special  interpretation.  Figure  3  provides 
this  interpretation.  Key  issues  are  whether  the  software  will  be  modified,  whether 
unmodified  software  constitutes  an  entire  CSCI  or  only  one  or  more  software  units, 
and  whether  unmodified  software  has  a  positive  performance  record  (no  firm  criteria 
exist  for  making  this  determination).  The  figure  is  presented  in  a  conditional  manner: 
If  an  activity  in  the  left  column  is  required  for  a  given  type  of  software,  the  figure  tells 
how  to  interpret  the  activity  for  reusable  software  of  that  type. 
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If  this 

MIL-STD-498 
activity  is 
required: 

Interpret  the  activity  as  follows  for  each  type  of  existing,  reusable  software: 

For  CSCIs  to  be  used  unmodified 

For  software  units  to  be  used 
unmodified 

For  software 
units  being 
modified  for / 
during  project 

Positive 

performance 

record 

No  or  poor 

performance 

record 

Positive 

performance 

record 

No  or  poor 

performance 

record 

5.1  Project 
planning  and 
oversight 

Include  the  activities  in  this  figure  in  project  plans 

5.2  Establishing 
software  devel 
environment 

Establish  and  apply  a  software  test  environment,  software  development 
library,  and  software  development  files  as  appropriate  to  perform  the 
activities  in  this  figure 

Apply  full 
requirements 

5.3  System 

requirements 

analysis 

Consider  software's  capabilities  in  defining  the  operational  concept  &  system  requirements  || 

Use  test / 
performance 
records  to 
confirm  ability  to 
meet  needs 

Test  to  confirm 
ability  to  meet 
needs 

Use  test/ 
performance 
records  to 
confirm  ability 
to  meet  needs 

Test  to 
confirm  ability 
to  meet 
needs 

Use  tests  or 
records  to 
determine 
potential  to 
meet  needs 

5.4.1  System- 
wide  design 

Consider  the  software's  capabilities  and  characteristics  in  designing  system  behavior  and  in 
making  other  system-wide  design  decisions 

5.4.2  System 

architectural 

design 

Include  the  CSCI  in  the  system 
architecture;  allocate  system 
requirements  to  it 

Consider  the  unit’s  capabilities  and  characteristics 
in  designating  CSCIs  and  allocating  system 
requirements  to  them 

5.5  Software 
requirements 
analysis 

Specify  the  project-specific 
requirements  the  CSCI  must  meet; 
verify  via  records  or  retest  that  the 
CSCI  can  meet  them 

Consider  the  unit's  capabilities  and  characteristics 
in  specifying  the  requirements  for  the  CSCI  of 
which  it  is  a  part 

5.6.1  CSCI- 
wide  design 

No  requirement:  the  CSCI-wide 
design  decisions  have  already  been 
made  (recording  the  "as  built"  design 
is  under  5.13) 

Consider  the  unit's  capabilities  and  characteristics 
in  designing  CSCI  behavior  and  making  other 
CSCI-wide  design  decisions 

5.6.2  CSCI 

architectural 

design 

No  requirement:  the  CSCI's 
architecture  is  already  defined 
(recording  the  "as  built"  design  is 
under  5.13) 

Include  the  unit  in  the  CSCI  architecture  and 
allocate  CSCI  requirements  to  it 

5.6.3  CSCI 
detailed  design 

No  requirement:  the  CSCI's  detailed 
design  is  already  defined  (recording 
the  "as  built’  design  is  under  5.13) 

No  requirement:  the  unit  is 
already  designed  (recording  the 
"as  built"  design  is  under  5.13) 

Modify  the 
unit's  design 
as  needed 

5.7.1  Software 
implementation 

No  requirement:  the  software  for  the 
CSCI's  units  is  already  implemented 

No  requirement:  the  software 
for  the  unit  is  already 
implemented 

Modify  the 
software  for 
the  unit 

5. 7. 2-5.7. 5 

Unit  testing 

... 

No  requirement: 
the  CSCI's  units 
are  already 
tested 

Perform 
selectively  if  in 
question  and  units 
are  accessible 

No  requirement: 
the  unit  is 
already  tested 

Perform  this  testing 

FIGURE  3.  Interpreting  MIL-STD-498  for  incorporation  of  reusable  software. 


34 


MIL-STD-498 
APPENDIX  B 


If  this 

MIL-STD-498 
activity  is 
required: 

Interpret  the  activity  as  follows  for  each  type  of  existing,  reusable  software: 

For  CSCIs  to  be  used  unmodified 

For  software  units  to  be  used 
unmodified 

For  software 
units  being 
modified  for/ 
during  project 

Positive 

performance 

record 

No  or  poor 

performance 

record 

Positive 

performance 

record 

No  or  poor 

performance 

record 

5.8  Unit 
integration  and 
testing 

No  requirement: 
the  CSCI's  units 
are  already 
integrated 

Perform 
selectively  if  in 
question  and  units 
are  accessible 

Perform  except 
where  integra¬ 
tion  is  already 
tested/proven 

Perform  this  testing 

5.9  CSCI 

qualification 

testing 

No  requirement: 
CSCI  is  already 
tested  &  proven 

Perform  this 
testing 

Include  the  unit  in  CSCI  qualification  testing 

5.10 

CSCI/HWCI 
integration  and 
testing 

Perform,  except 
where  integra¬ 
tion  is  already 
tested/proven 

Include  the  CSCI 
in  CSCI/HWCI 
integration  and 
testing 

Include  the  unit  in 

CSCI/HWCI  integration  and  testing 

5.1 1  System 

qualification 

testing 

Include  the  CSCI  in 
system  qualification  testing 

Include  the  unit  in  system  qualification  testing 

5.12  Preparing 
for  software 

use 

Include  the  software  for  the  CSCI  or  unit  in  the  executable  software;  include  in  version 
descriptions;  handle  any  license  issues;  cover  use  of  the  CSCI  or  unit,  as  appropriate,  via 
existing,  new,  or  revised  user/operator  manuals;  install  the  CSCI  or  unit  as  part  of  the 
overall  system;  include  its  use,  as  appropriate,  in  the  training  offered 

5.13  Preparing 
for  software 
transition 

Include  the  software  for  the  CSCI  or  unit  in  the  executable  software;  prepare  source  files 
for  the  CSCI  or  unit,  if  available;  include  in  version  descriptions;  handle  any  license  issues; 
prepare  or  provide  "as  built"  design  descriptions  for  software  whose  design  is  known; 
install  the  CSCI  or  unit  at  the  support  site;  demonstrate  regenerability  if  source  is  available; 
include  in  the  training  offered 

5.14  Software 

configuration 

management 

Apply  to  all  software  products  prepared,  modified,  or  used  in  incorporating  this  software 

5.15  Software 

product 

evaluation 

Apply  to  all  software  products  prepared  or  modified  in  incorporating  this  software;  for 
software  products  used  unchanged,  apply  unless  a  positive  performance  record  or  evidence 
of  past  evaluations  indicates  that  such  an  evaluation  would  be  duplicative 

5.16  Software 

quality 

assurance 

Apply  to  all  activities  performed  and  all  software  products  prepared,  modified,  or  used  in 
incorporating  this  software 

5.17  Corrective 
action 

Apply  to  all  activities  performed  and  all  software  products  prepared  or  modified  in 
incorporating  this  software 

5.18  Joint 
reviews 

Cover  the  so^vare  products  prepared  or  modified  in  incorporating  this  software 

5.1 9  Other 
activities 

Apply  the  full  requirements  of  this  section 

FIGURE  3.  Interpreting  MIL-STD-498  for  incorporation  of  reusable  software  -  continued. 
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CATEGORY  AND  PRIORITY  CLASSIFICATIONS 
FOR  PROBLEM  REPORTING 

C.1  Scope.  This  appendix  contains  requirements  for  a  category  and  priority  classification 
scheme  to  be  applied  to  each  problem  submitted  to  the  corrective  action  system.  This 
appendix  is  a  mandatory  part  of  the  standard,  subject  to  the  following  conditions:  1)  these 
requirements  may  be  tailored  by  the  acquirer,  and  2)  the  developer  may  use  alternate  category 
and  priority  schemes  if  approved  by  the  acquirer. 

C.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

C.3  Classification  bv  category.  The  developer  shall: 

a.  Assign  each  problem  in  software  products  to  one  or  more  of  the  categories  in 
Figure  4. 

b.  Assign  each  problem  in  activities  to  one  or  more  of  the  categories  in  Figure  1 
(shown  at  the  start  of  Section  5). 

C.4  Classification  bv  priority.  The  developer  shall  assign  each  problem  in  software 
products  or  activities  to  one  of  the  priorities  in  Figure  5. 


APPENDIX  C 


Category 

Applies  to  problems  in: 

a.  Plans 

One  of  the  plans  developed  for  the  project 

b.  Concept 

The  operational  concept 

c.  Requirements 

The  system  or  software  requirements 

d.  Design 

The  design  of  the  system  or  software 

e.  Code 

The  software  code 

f.  Database/data  file 

A  database  or  data  file 

g.  Test  information 

Test  plans,  test  descriptions,  or  test  reports 

h.  Manuals 

The  user,  operator,  or  support  manuals 

i.  Other 

Other  software  products 

Priority 


1 


Applies  if  a  problem  could: 


a.  Prevent  the  accomplishment  of  an  operational  or  mission  essential  capability 

b.  Jeopardize  safety,  security,  or  other  requirement  designated  "critical" 


a.  Adversely  affect  the  accomplishment  of  an  operational  or  mission  essential 
capability  and  no  work-around  solution  is  known 

b.  Adversely  affect  technical,  cost,  or  schedule  risks  to  the  project  or  to  life 
cycle  support  of  the  system,  and  no  work-around  solution  is  known 


a.  Adversely  affect  the  accomplishment  of  an  operational  or  mission  essential 
capability  but  a  work-around  solution  is  known 

b.  Adversely  affect  technical,  cost,  or  schedule  risks  to  the  project  or  to  life 
cycle  support  of  the  system,  but  a  work-around  solution  is  known 


a.  Result  in  user/operator  inconvenience  or  annoyance  but  does  not  affect  a 
required  operational  or  mission  essential  capability 

b.  Result  in  inconvenience  or  annoyance  for  development  or  support  personnel, 
but  does  not  prevent  the  accomplishment  of  those  responsibilities 


Any  other  effect 
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SOFTWARE  PRODUCT  EVALUATIONS 

D.1  Scope.  This  appendix  identifies  the  software  products  that  are  to  undergo  software 
product  evaluations,  identifies  the  criteria  to  be  used  for  each  evaluation,  and  contains  a 
default  set  of  definitions  for  the  evaluation  criteria.  This  appendix  is  a  mandatory  part  of  the 
standard,  subject  to  the  following  conditions:  1)  these  requirements  may  be  tailored  by  the 
acquirer,  2)  the  developer  may  use  alternate  criteria  or  definitions  if  approved  by  the  acquirer, 
and  3)  if  the  development  of  a  given  software  product  has  been  tailored  out  of  the  standard, 
the  requirement  to  evaluate  that  product  does  not  apply. 

D.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

D.3  Required  evaluations.  Figure  6  identifies  the  software  products  that  are  to  undergo 
software  product  evaluations  and  states  the  criteria  to  be  applied  to  each  one.  Each  software 
product  and  criterion  is  labelled  for  purposes  of  identification  and  tailoring.  For  convenience, 
they  may  be  treated  as  subparagraphs  of  this  paragraph  (referring  to  the  first  criterion,  for 
example,  as  D.3.1  .a).  The  software  products  are  expressed  in  lower  case  letters  to  convey 
generic  products,  not  necessarily  in  the  form  of  hard-copy  documents.  Evaluations  of  system- 
level  products  are  to  be  interpreted  as  participation  in  these  evaluations.  Some  of  the  criteria 
are  subjective.  Because  of  this,  there  is  no  requirement  to  prove  that  the  criteria  have  been 
met;  the  requirement  is  to  perform  the  evaluations  using  these  criteria  and  to  identify  possible 
problems  for  discussion  and  resolution. 

D.4  Criteria  definitions.  The  following  paragraphs  provide  definitions  for  the  criteria  in 
Figure  6  that  may  not  be  self-explanatory.  The  criteria  are  iisted  in  alphabetical  order, 
matching  as  closely  as  possible  the  wording  used  in  Figure  6. 

D.4.1  Accurately  describes  (an  item).  This  criterion,  applied  to  user/operator/programmer 
instructions  and  to  the  "as  built"  design  and  version  descriptions,  means  that  the  instructions 
or  descriptions  are  correct  depictions  of  the  software  or  other  item  described. 

D.4. 2  Adequate  test  cases,  procedures,  data,  results.  Test  cases  are  adequate  if  they  cover 
all  applicable  requirements  or  design  decisions  and  specify  the  inputs  to  be  used,  the  expected 
results,  and  the  criteria  to  be  used  for  evaluating  those  results.  Test  procedures  are  adequate 
if  they  specify  the  steps  to  be  followed  in  carrying  out  each  test  case.  Test  data  are  adequate 
if  they  enable  the  execution  of  the  planned  test  cases  and  test  procedures.  Test  or  dry  run 
results  are  adequate  if  they  describe  the  results  of  all  test  cases  and  show  that  all  criteria  have 
been  met,  possibly  after  revision  and  retesting. 

D.4. 3  Consistent  with  indicated  product(s).  This  criterion  means  that:  (1 )  no  statement  or 
representation  in  one  software  product  contradicts  a  statement  or  representation  in  the  other 
software  products,  (2)  a  given  term,  acronym,  or  abbreviation  means  the  same  thing  in  all  of 
the  software  products,  and  (3)  a  given  item  or  concept  is  referred  to  by  the  same  name  or 
description  in  all  of  the  software  products. 

* 

D.4.4  Contains  all  applicable  information  in  (a  specified  DID).  This  criterion  uses  the  DIDs 
to  specify  the  required  content  of  software  products,  regardless  of  whether  a  deliverable 
document  has  been  ordered.  Allowances  are  to  be  made  for  the  applicability  of  each  DID 
topic.  The  formatting  specified  in  the  DID  (required  paragraphing  and  numbering)  are  not 
relevant  to  this  evaluation. 
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FIGURE  6.  Software  products  and  associated  evaluation  criteria. 
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FIGURE  6.  Software  products  and  associated  evaluation  criteria  -  continued. 
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D.4.5  Covers  (a  oiven  set  of  items).  A  software  product  "covers"  a  given  set  of  items  if 
every  item  in  the  set  has  been  dealt  with  in  the  software  product.  For  example,  a  plan  covers 
the  SOW  if  every  provision  in  the  SOW  is  dealt  with  in  the  plan;  a  design  covers  a  set  of 
requirements  if  every  requirement  has  been  dealt  with  in  the  design;  a  test  plan  covers  a  set 
of  requirements  if  every  requirement  is  the  subject  of  one  or  more  tests.  "Covers" 
corresponds  to  the  downward  traceability  {for  example,  from  requirements  to  design)  in  the 
requirement,  design,  and  test  planning/description  DIDs. 

D.4.6  Feasible.  This  criterion  means  that,  in  the  knowledge  and  experience  of  the 
evaluator,  a  given  concept,  set  of  requirements,  design,  test,  etc.  violates  no  known  principles 
or  lessons  learned  that  would  render  it  impossible  to  carry  out. 

D.4.7  Follows  software  development  plan.  This  criterion  means  that  the  software  product 
shows  evidence  of  having  been  developed  in  accordance  with  the  approach  described  in  the 
software  development  plan.  Examples  include  following  design  and  coding  standards 
described  in  the  plan.  For  the  software  development  plan  itself,  this  criterion  applies  to 
updates  to  the  initial  plan. 

D.4.8  Internally  consistent.  This  criterion  means  that;  (1)  no  two  statements  or 
representations  in  a  software  product  contradict  one  another,  (2)  a  given  term,  acronym,  or 
abbreviation  means  the  same  thing  throughout  the  software  product,  and  (3)  a  given  item  or 
concept  is  referred  to  by  the  same  name  or  description  throughout  the  software  product. 

D.4.9  Meets  CDRL.  if  applicable.  This  criterion  applies  if  the  software  product  being 
evaluated  is  specified  in  the  CDRL  and  has  been  formatted  for  delivery  at  the  time  of 
evaluation.  It  focuses  on  the  format,  markings,  and  other  provisions  specified  in  the  CDRL, 
rather  than  on  content,  covered  by  other  criteria. 

D.4.10  Meets  SOW,  if  applicable.  This  criterion  means  that  the  software  product  fulfills  any 
Statement  of  Work  provisions  regarding  it.  For  example,  the  Statement  of  Work  may  place 
constraints  on  the  operational  concept  or  the  design. 

D.4.1 1  Presents  a  sound  approach.  This  criterion  means  that,  based  on  the  knowledge  and 
experience  of  the  evaluator,  a  given  plan  represents  a  reasonable  way  to  carry  out  the 
required  activities. 

D.4.1 2  Shows  evidence  that  (an  item  under  test)  meets  its  requirements.  This  criterion 
means  that  recorded  test  results  show  that  the  item  under  test  either  passed  all  tests  the  first 
time  or  was  revised  and  retested  until  .the  tests  were  passed. 

D.4.1 3  Testable.  A  requirement  or  set  of  requirements  is  considered  to  be  testable  if  an 
objective  and  feasible  test  can  be  designed  to  determine  whether  each  requirement  has  been 
met. 

D.4.1 4  Understandable.  This  criterion  means  "understandable  by  the  intended  audience." 
For  example,  software  products  intended  for  programmer-to-programmer  communication  need 
not  be  understandable  by  non-programmers.  A  product  that  correctly  identifies  its  audience 
(based  on  information  in  Block  3  of  the  corresponding  DID)  and  is  considered  understandable 
to  that  audience  meets  this  criterion. 
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CANDIDATE  JOINT  MANAGEMENT  REVIEWS 

E.1  Scope.  This  appendix  describes  a  candidate  set  of  joint  management  reviews  that 
might  be  held  during  a  software  development  project.  This  appendix  is  not  a  mandatory  part 
of  this  standard.  The  information  provided  is  intended  for  guidance  only. 

E.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

E.3  Assumptions.  This  appendix  makes  the  following  assumptions: 

a.  The  acquirer  has  reviewed  the  subject  products  in  advance,  and  one  or  more  joint 
technical  reviews  have  been  held  to  resolve  issues,  leaving  the  joint  management 
review  as  a  forum  to  resolve  open  issues  and  reach  agreement  as  to  the  acceptability 
of  each  product. 

b.  Any  of  the  reviews  may  be  conducted  incrementally,  dealing  at  each  review  with  a 
subset  of  the  listed  items  or  a  subset  of  the  system  or  CSCI(s)  being  reviewed. 

E.4  Candidate  reviews.  Given  below  is  a  set  of  candidate  joint  management  reviews  that 
might  be  held  during  a  software  development  project.  There  is  no  intent  to  require  these 
reviews  or  to  preclude  alternatives  or  combinations  of  these  reviews.  The  objectives 
supplement  those  given  in  5.18.2. 

E.4.1  Software  plan  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding  one 
or  more  of  the  following: 

a.  The  software  development  plan 

b.  The  software  test  plan 

c.  The  software  installation  plan 

d.  The  software  transition  plan 

E.4.2  Operational  concept  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding 
the  operational  concept  for  a  software  system. 

E.4. 3  Svstem/subsvstem  requirements  reviews.  These  reviews  are  held  to  resolve  open 
issues  regarding  the  specified  requirements  for  a  software  system  or  subsystem. 

E.4. 4  Svstem/subsvstem  design  reviews.  These  reviews  are  held  to  resolve  open  issues 
regarding  one  or  more  of  the  following: 

a.  The  system-  or  subsystem-wide  design  decisions 

b.  The  architectural  design  of  a  software  system  or  subsystem 

E.4. 5  Software  requirements  reviews.  These  reviews  are  held  to  resolve  open  issues 
regarding  the  specified  requirements  for  a  CSCI. 
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E.4.6  Software  desian  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding  one 
or  more  of  the  following: 

a.  The  CSCI-wide  design  decisions 

b.  The  architectural  design  of  a  CSCI 

c.  The  detailed  design  of  a  CSCI  or  portion  thereof  (such  as  a  database) 

E.4.7  Test  readiness  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding  one 
or  more  of  the  following: 

a.  The  status  of  the  software  test  environment 

b.  The  test  cases  and  test  procedures  to  be  used  for  CSCI  qualification  testing  or  system 
qualification  testing 

c.  The  status  of  the  software  to  be  tested 

E.4.8  Test  results  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding  the 
results  of  CSCI  qualification  testing  or  system  qualification  testing. 

E.4.9  Software  usability  reviews.  These  reviews  are  held  to  resolve  open  issues  regarding 
one  or  more  of  the  following: 

a.  The  readiness  of  the  software  for  installation  at  user  sites 

b.  The  user  and  operator  manuals 

c.  The  software  version  descriptions 

d.  The  status  of  installation  preparations  and  activities 

E.4.10  Software  supportabilitv  reviews.  These  reviews  are  held  to  resolve  open  issues 
regarding  one  or  more  of  the  following: 

a.  The  readiness  of  the  software  for  transition  to  the  support  agency 

b.  The  software  product  specifications 

c.  The  software  support  manuals 

d.  The  software  version  descriptions 

e.  The  status  of  transition  preparations  and  activities,  including  transition  of  the  software 
development  environment,  if  applicable 

E.4.11  Critical  requirement  reviews.  These  reviews  are  held  to  resolve  open  issues 
regarding  the  handling  of  critical  requirements,  such  as  those  for  safety,  security,  and  privacy. 
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CANDIDATE  MANAGEMENT  INDICATORS 

F.1  Scope.  This  appendix  identifies  a  set  of  management  indicators  that  might  be  used 
on  a  software  development  project.  This  appendix  is  not  a  mandatory  part  of  this  standard. 
The  information  provided  is  intended  for  guidance  only. 


F.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

F.3  Candidate  indicators.  Given  below  is  a  set  of  candidate  management  indicators  that 
might  be  used  on  a  software  development  project.  There  is  no  intent  to  impose  these 
indicators  or  to  preclude  others. 


a.  Requirements  volatility:  total  number  of  requirements  and  requirement  changes  over 
time. 


b.  Software  size:  planned  and  actual  number  of  units,  lines  of  code,  or  other  size 
measurement  over  time. 

i 

c.  Software  staffing:  planned  and  actual  staffing  levels  over  time. 

d.  Software  complexity:  complexity  of  each  software  unit. 


e.  Software  progress:  planned  and  actual  number  of  software  units  designed, 
implemented,  unit  tested,  and  integrated  over  time. 


f.  Problem/change  report  status:  total  number,  number  closed,  number  opened  in  the 
current  reporting  period,  age,  priority. 


g.  Build  release  content:  planned  and  actual  number  of  software  units  released  in  each 
build. 


h.  Computer  hardware  resource  utilization:  planned  and  actual  use  of  computer  hardware 
resources  (such  as  processor  capacity,  memory  capacity,  input/output  device 
capacity,  auxiliary  storage  device  capacity,  and  communications/network  equipment 
capacity)  over  time. 

i.  Milestone  performance:  planned  and  actual  dates  of  key  project  milestones. 

j.  Scrap/rework:  amount  of  resources  expended  to  replace  or  revise  software  products 
after  they  are  placed  under  project-level  or  higher  configuration  control. 


Effect  of  reuse:  a  breakout  of  each  of  the  indicators  above  for  reused  versus  new 
software  products. 
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GUIDANCE  ON  PROGRAM  STRATEGIES,  TAILORING,  AND  BUILD  PLANNING 

G.1  Scope.  This  appendix  identifies  three  of  the  program  strategies  used  by  DoD  and 
shows  how  MIL-STD-498  can  be  applied  under  each  of  these  strategies  and  on  a  project 
involving  reengineering.  This  appendix  is  not  a  mandatory  part  of  the  standard.  The 
information  provided  is  intended  for  guidance  only. 

G.2  Applicable  documents.  Documents  cited  in  this  appendix  are  as  follows: 

a.  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures 

b.  DODI  8120.2,  Automated  Information  System  Life-Cycle  Management  Process, 
Review,  and  Milestone  Approval 

G.3  Candidate  program  strategies.  DODI  8 1 20.2  describes  three  basic  program  strategies 
plus  a  generic  strategy  called  "other,"  encompassing  variations,  combinations,  and  alternatives 
to  the  three.  DODI  5000.2  identifies  similar  strategies,  called  acquisition  strategies.  The 
three  basic  strategies  are  summarized  below  and  in  Figure  7. 

a.  Grand  design.  The  "grand  design"  strategy  (not  named  in  DODI  5000.2  but  treated 
as  one  strategy)  is  essentially  a  "once-through,  do-each-step-once"  strategy. 
Simplistically:  determine  user  needs,  define  requirements,  design  the  system, 
implement  the  system,  test,  fix,  and  deliver. 

b.  Incremental.  The  "incremental"  strategy  (called  "Preplanned  Product  Improvement" 
in  DODI  5000.2)  determines  user  needs  and  defines  the  system  requirements,  then 
performs  the  rest  of  the  development  in  a  sequence  of  builds.  The  first  build 
incorporates  part  of  the  planned  capabilities,  the  next  build  adds  more  capabilities,  and 
so  on,  until  the  system  is  complete. 

c.  Evolutionary.  The  "evolutionary"  strategy  (called  "evolutionary"  in  both  DOD 
Instructions)  also  develops  a  system  in  builds,  but  differs  from  the  incremental  strategy 
in  acknowledging  that  the  user  need  is  not  fully  understood  and  all  requirements 
cannot  be  defined  up  front.  In  this  strategy,  user  needs  and  system  requirements  are 
partially  defined  up  front,  then  are  refined  in  each  succeeding  build. 


Program  Strategy 

Define  All 

Requirements  First? 

Multiple 

Development 

Cycles? 

Field  Interim 
Software? 

Grand  Design 

Yes 

No 

No 

Incremental  (Preplanned 
Product  Improvement) 

Yes 

Yes 

Maybe 

Evolutionary 

No 

Yes 

Yes 

FIGURE  7. 


Kev  features  of  three  DOD  program  strategies. 
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G.4  Selecting  an  appropriate  program  strategy.  The  program  strategy  is  selected  by  the 
acquirer,  but  may  be  proposed  by  prospective  or  selected  developers.  Figure  8  illustrates  a 
risk  analysis  approach  for  selecting  an  appropriate  strategy.  The  approach  consists  of  listing 
risk  items  (negatives)  and  opportunity  items  (positives)  for  each  strategy;  assigning  each  item 
a  risk  or  opportunity  level  of  High,  Medium,  or  Low;  and  making  a  decision  on  which  strategy 
to  use  based  on  a  trade-off  among  the  risks  and  opportunities.  The  fill-ins  shown  are  sample 
considerations  only.  An  actual  analysis  may  use  others.  The  "DECISION"  entry  on  the 
bottom  line  shows  which  strategy  was  selected. 

G.5  Relationship  of  MIL-STD-498  to  program  strategies.  The  program  strategy  usually 
applies  to  the  overall  system.  The  software  within  the  system  may  be  acquired  under  the 
same  strategy  or  under  a  different  one,  such  as  requiring  that  all  software  be  finalized  in  the 
first  build  of  the  system.  Figures  9,  10,  and  11  show  how  MIL-STD-498  might  be  applied 
under  each  of  the  program  strategies  identified  in  G.3.  Figure  1 2  shows  how  MIL-STD-498 
might  be  applied  on  a  reengineering  project.  All  four  figures  are,  by  necessity,  simplified.  For 
example,  they  show  MIL-STD-498  activities  in  sequence  when  they  might  actually  be  ongoing, 
overlapping,  or  iterative;  they  show  each  software  product  as  a  single  entity,  without 
depicting  early  drafts  or  updates;  and  they  represent  each  software  product  by  the  name  of 
the  corresponding  DID,  when  the  actual  software  product  is  the  information  called  for  by  the 
DID,  not  necessarily  in  the  form  of  a  hard-copy  document. 

G.6  Planning  software  builds  and  tailoring  MIL-STD-498.  Planning  the  software  builds  on 
a  project  and  tailoring  MIL-STD-498  for  each  build  may  be  accomplished  in  several  ways.  The 
acquirer  might,  for  example,  select  an  overall  program  strategy  and  tailor  the  standard  for  the 
overall  contract,  leaving  it  to  the  developer  to  lay  out  the  software  builds  and  propose  the 
tailoring  for  each  build.  Alternatively,  the  acquirer  might  lay  out  the  software  builds  and 
specify  the  tailoring  for  each  as  part  of  the  contract.  The  approach  selected  will  be  project- 
dependent.  The  paragraphs  below  provide  guidelines  for  planning  the  builds  and  tailoring  the 
standard  without  attempting  to  divide  these  activities  between  the  acquirer  and  developer. 

G.6.1  Identifying  builds  and  their  objectives.  The  first  step  in  software  build  planning  is  to 
lay  out  a  series  of  one  or  more  builds  and  to  identify  the  objectives  of  each  build.  The  top 
part  of  Figure  13  illustrates  such  planning.  In  the  example,  the  system/subsystem 
specification  (SSS)  already  exists  and  fulfillment  of  its  requirements  is  divided  into  four  builds, 
two  of  which  will  be  prototypes  delivered  to  a  selected  set  of  users,  and  two  of  which  will 
actually  be  fielded.  A  further  objective  of  Build  4  is  transitioning  the  software  to  the 
designated  support  agency.  An  actual  project  would  expand  on  these  objectives. 

G.6. 2  Identifying  the  MIL-STD-498  activities  to  be  performed  in  each  build.  The  next  step 
in  build  planning  is  identifying  which  MIL-STD-498  activities  apply  in  each  build  and 
determining  the  extent  to  which  they  apply.  The  lower  part  of  Figure  13  shows  the  start  of 
such  planning.  Listed  on  the  left  are  the  paragraphs  of  MIL-STD-498.  The  worksheet  entries 
indicate  in  which  builds  each  activity  is  to  be  performed  and  include  any  notes  regarding  the 
nature  of  each  activity  in  each  build.  For  example,  the  figure  shows  that  each  build  will 
include  software  development  planning  (5.1.1),  but  that  the  nature  of  that  planning  changes 
in  each  build.  Some  activities  will  not  apply  at  all  in  a  given  build,  some  will  apply  identically 
in  all  builds,  and  some  will  apply  differently  in  different  builds.  Since  some  aspects  of  the 
project,  such  as  number  and  type  of  CSCIs,  may  not  have  been  identified  at  the  time  the 
worksheet  is  being  filled  out,  completion  of  the  worksheet  may  itself  be  incremental.  The 
following  guidelines  apply: 
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FIGURE  8.  Sample  risk  analysis  for  determining  the  appropriate  program  strategy. 
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FIGURE  9.  Qr»e  possible  wav  of  applying  MIL-STD-498  to  the  Grand  Design  program  stratei 
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FIGURE  10.  One  possible  wav  of  applying  MIL-STD-498  to  the  Incremental  program  strate 
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FIGURE  12.  One  possible  wav  of  applying  MIL-STD-498  to  a  reengineering  project. 
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FIGURE  13.  Example  of  build  planning  for  a  MIL-STD-498  project. 
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a.  Different  decisions  will  apply  to  different  types  of  software  on  a  project.  These 
differences  can  be  shown  within  the  entries  of  one  worksheet  or  by  using  different 
worksheets  for  different  types  of  software  on  a  project. 

b.  If  early  builds  are  devoted  to  experimentation,  developing  "throw-away"  software  to 
arrive  at  a  system  concept  or  system  requirements,  it  may  be  appropriate  to  forgo 
certain  formalities,  such  as  coding  standards,  that  will  be  imposed  later  on  the  "real" 
software.  If  the  early  software  will  be  used  later,  such  formalities  may  be  appropriate 
from  the  start.  These  decisions  are  project-dependent. 

G.6.3  Recording  tailoring  decisions.  Tailoring  decisions  made  by  the  acquirer  before  the 
project  begins  are  specified  in  the  Statement  of  Work.  Tailoring  proposed  by  the  developer 
may  be  communicated  via  feedback  on  draft  solicitations,  proposals  written  in  response  to 
solicitations,  the  software  development  plan,  joint  reviews  during  the  project,  or  by  other 
means  of  communication.  Refinements  to  the  tailoring  decisions  may  be  ongoing  as  the 
project  proceeds.  Those  involving  contractual  changes  should  be  handled  accordingly. 

G.6.4  Scheduling  the  selected  activities  in  each  build.  Another  important  step  in  build 
planning  is  scheduling  the  activities  in  each  build.  As  with  tailoring,  the  acquirer  may  set  forth 
general  milestones  and  have  the  developer  provide  specifics  or  may  provide  specific 
schedules.  The  following  guidelines  apply: 

a.  A  common  mistake  is  to  treat  all  CSCIs  as  though  they  must  be  developed  in  "lock- 
step,"  reaching  key  milestones  at  the  same  time.  Allowing  CSCIs  to  be  on  different 
schedules  can  result  in  more  optimum  development. 

b.  A  similar  mistake  is  to  treat  software  units  as  though  they  must  be  developed  in  "lock- 
step,"  all  designed  by  a  certain  date,  implemented  by  a  certain  date,  etc.  Flexibility 
in  the  scheduling  of  software  units  can  also  be  effective. 

c.  The  activities  in  MIL-STD-498  need  not  be  performed  sequentially.  Several  may  be 
taking  place  at  one  time,  and  an  activity  may  be  performed  continually  or  intermittently 
throughout  a  build  or  over  multiple  builds.  The  activities  in  each  build  should  be  laid 
out  in  the  manner  that  best  suits  the  work  to  be  done. 
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APPENDIX  H 

GUIDANCE  ON  ORDERING  DELIVERABLES 

H.1  Scope.  This  appendix  provides  guidance  to  the  acquirer  on  the  deliverables  to  be 
required  on  a  software  development  project.  This  appendix  is  not  a  mandatory  part  of  this 
standard.  The  information  provided  is  intended  for  guidance  only. 

H.2  Applicable  documents.  This  section  is  not  applicable  to  this  appendix. 

H.3  Ordering  deliverables.  MIL-STD-498  has  been  worded  to  differentiate  between  the 
planning/engineering  activities  that  make  up  a  software  development  project  and  the 
generation  of  deliverables.  A  key  objective  of  this  wording  is  to  eliminate  the  notion  that  the 
acquirer  must  order  a  given  deliverable  in  order  to  have  planning  or  engineering  work  take 
place.  Under  MIL-STD-498,  the  planning  and  engineering  work  takes  place  regardless  of 
which  deliverables  are  ordered,  unless  a  given  activity  is  tailored  out  of  the  standard.  In 
addition,  joint  technical  reviews  have  been  included  to  review  the  results  of  that  work  in  its 
natural  form,  without  the  generation  of  deliverables.  Deliverables  should  be  ordered  only 
when  there  is  a  genuine  need  to  have  planning  or  engineering  information  transformed  into 
a  deliverable,  recognizing  that  this  transformation  requires  time  and  effort  that  would 
otherwise  be  spent  on  the  engineering  effort.  Block  3  of  each  DID  provides  information 
helpful  in  deciding  whether  the  corresponding  deliverable  should  be  ordered. 

H.4  Scheduling  deliverables.  MIL-STD-498  has  been  structured  to  support  a  variety  of 
program  strategies  and  to  provide  the  developer  flexibility  in  laying  out  a  software 
development  process  that  will  best  suit  the  work  to  be  done.  All  of  this  flexibility  can  be 
canceled  by  rigid  scheduling  of  deliverables  on  the  CDRL.  If  the  CDRL  lays  out  a  strict 
"waterfall"  sequence  of  deliverables,  little  room  is  left  to  propose  innovative  development 
processes.  If  the  CDRL  forces  all  CSCIs  into  lock-step  with  each  other,  little  room  is  left  to 
develop  the  CSCIs  in  an  optimum  order.  To  the  maximum  extent  possible,  the  CDRL  should 
avoid  such  pre-determination,  leaving  the  door  open  for  incremental  delivery  of  software 
products,  staggered  development  of  CSCIs,  and  other  variations  to  optimize  the  software 
development  effort.  The  developer's  software  development  plan  will  lay  out  a  proposed 
schedule  that  meets  the  constraints  in  the  CDRL.  Final  agreement  on  scheduling  can  take 
place  at  that  time. 

H.5  Format  of  deliverables.  Traditional  deliverables  take  the  form  of  paper  documents 
exactly  following  DID  formats.  While  this  form  works  well  for  some  deliverables,  it  is  not  the 
only  form,  and  alternatives  should  be  considered.  One  variation  from  paper  documents  is 
word  processing  files  containing  those  documents.  This  format  saves  paper,  but  still  requires 
the  developer  to  format  the  information  as  required  by  the  DID.  Another  variation  is 
specifying  that  a  paper  or  word  processor  document  is  to  include  all  DID  contents  but  may 
be  in  the  developer's  format.  Yet  another  variation  is  allowing  deliverables  to  take  forms  that 
are  not  traditional  documents  at  all,  such  as  data  in  computer-aided  software  engineering 
(CASE)  tools.  These  variations  in  required  format  can  be  specified  on  the  CDRL,  minimizing 
the  time  spent  transforming  actual  work  products  into  deliverables. 

H.6  Tailoring  the  DIDs.  Tailoring  the  DIDs  consists  of  deleting  requirements  for  unneeded 
information  and  making  other  changes  that  do  not  increase  the  required  workload,  such  as 
combining  two  documents  under  one  cover.  DID  tailoring  for  deliverables  is  specified  in  Block 
1  6  of  the  CDRL. 
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CONVERSION  GUIDE  FROM 
DOD-STD-21 67A  AND  DOD-STD-7935A 


1.1  Scope.  This  appendix  provides  a  conversion  guide  from  DOD-STD-21 67A  and  DOD- 
STD-7935A,  the  two  standards  that  were  merged  to  form  MIL-STD-498.  It  maps  key  terms 
from  each  of  these  standards  to  their  counterparts  in  MIL-STD-498  and  shows  the  relationship 
of  the  DIDs  required  by  these  standards  to  their  counterparts  in  MIL-STD-498.  This  appendix 
is  not  a  mandatory  part  of  the  standard.  The  information  provided  is  intended  for  guidance 
only. 

1.2  Applicable  documents.  This  appendix  references  the  following  standards,  both  of 
which  are  superseded  by  this  standard: 

a.  DOD-STD-21 67A,  Defense  System  Software  Development,  29  February  1988 


b.  DOD-STD-7935A,  DoD  Automated  Information  System  Documentation  Standards, 
31  October  1988 


1.3  Mapping  of  kev  terms.  Figure  1 4  identifies  selected  terms  in  MIL-STD-498  and  states 
their  counterparts  in  DOD-STD-21 67A  and  DOD-STD-7935A. 


MIL-STD-498  Term 

DOD-STD-21 67 A  Counterpart 

DOD-STD-7935A  Counterpart 

Acquirer 

Contracting  agency 

User  Group  (no  distinction  made 
between  acquirer  and  user  roles) 

Developer 

Contractor  (covers  Government 
agency  or  contractor! 

Development  Group  (covers 
Government  agency  or  contractor) 

Implementation 

Coding 

Development,  production,  coding, 
database  generation 

Installation  (at  user  sites) 

Deployment 

Deployment,  implementation, 
installation 

Software  unit 

Computer  software  component 
and  computer  software  unit 

Software  unit 

Computer  Software 

Configuration  Item  (CSCI) 

Computer  Software  Configuration 
Item  (CSCI) 

Program,  computer  program 

Software  support 

Software  support 

Software  maintenance 

Software  system  (consisting  of 
software  and  possibly 
computers) 

System  (No  specific  term  used  to 
distinguish  this  type  of  system) 

Automated  Information  System, 
system 

Hardware-software  system 
(where  the  hardware  may  be 
other  than  computers) 

System  (No  specific  term  used  to 
distinguish  this  type  of  system) 

(This  type  of  system  not  covered 
by  DOD-STD-7935A) 

FIGURE  14.  Mapping  of  kev  terms. 
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1.4  Mapping  of  DIDs.  Figure  15  identifies  the  DOD-STD-7935A  DIDs  and  tells  which 
MIL-STD-498  DIDs  contain  their  contents.  Figure  16  provides  a  similar  mapping  from  the 
DOD-STD-21 67A  DIDs  to  the  MIL-STD-498  DIDs.  Figure  17  provides  the  reverse  mapping, 
identifying  the  MIL-STD-498  DIDs  and  telling  which  DOD-STD-21 67A  and/or  DOD-STD-7935A 
DIDs  formed  the  basis  for  each. 


DOD-STD-7935A  DID 

Incorporated  into  These  MIL-STD-498  DIDs 

Functional  Description  (FD) 

System  concepts  into  Operational  Concept  Description  (OCD) 

System  requirements  into  System/Subsystem  Specification  (SSS) 
Development  planning  into  Software  Development  Plan  (SDP) 

System/Subsystem  Specification 
(SS) 

System  requirements  into  System/Subsystem  Specification  (SSS) 

System  design  into  System/Subsystem  Design  Description  (SSDD) 

Software  Unit  Specification  (US) 

Requirement  information  into  Software  Requirements  Specification 
(SRS)  and  Interface  Requirements  Specification  (IRS) 

Design  information  into  Software  Design  Description  (SDD)  and 

Interface  Design  Description  (IDD) 

Database  Specification  (DS) 

Database  Design  Description  (DBDD) 

Test  Plan  (PT) 

High-level  planning  into  Software  Test  Plan  (STP) 

Detailed  planning  into  Software  Test  Description  (STD) 

Test  Analysis  Report  (RT) 

Software  Test  Report  (STR) 

Users  Manual  (UM) 

Software  Input/Output  Manual  (S)OM) 

End  User  Manual  (EM) 

Software  User  Manual  (SUM) 

Computer  Operation  Manual  (OM) 

Software  Center  Operator  Manual  (SCOM) 

Maintenance  Manual  (MM) 

Planning  information  into  Software  Transition  Plan  (STrP) 

Software  description  into  Software  Design  Description  (SDD) 

Maintenance  procedures  into  Software  Product 

Specification  (SPS) 

Implementation  Procedures  (IP) 

Software  Installation  Plan  (SIP) 

FIGURE  15.  Mapping  of  DOD-STD-7935A  DIDs  to  MIL-STD-498  DIDs. 
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DOD-STD-2 1 67 A  DID 

Incorporated  into  These  MIL-STD-498  DIDs 

Software  Development  Plan  (SDP) 

Software  Development  Plan  (SDP) 

System/Segment  Specification  (SSS) 

System/Subsystem  Specification  (SSS) 

System/Segment  Design  Document  (SSDD) 

Operational  concept  into  Operational  Concept  Description 
(OCD) 

System  design  into  System/Subsystem  Design  Description 
(SSDD) 

Software  Requirements  Specification  (SRS) 

Software  Requirements  Specification  (SRS) 

Interface  Requirements  Specification  (IRS) 

Interface  Requirements  Specification  (IRS) 

Software  Design  Document  (SDD) 

Software  Design  Description  (SDD) 

Interface  Design  Document  (IDD) 

Interface  Design  Description  (IDD) 

Software  Test  Plan  (STP) 

Software  Test  Plan  (STP) 

Software  Test  Description  (STD) 

Software  Test  Description  (STD) 

Software  Test  Report  (STR) 

Software  Test  Report  (STR) 

Computer  System  Operator's  Manual  (CSOM) 

Computer  Operation  Manual  (COM) 

Software  User's  Manual  (SUM) 

Software  User  Manual  (SUM) 

Computer  Resources  Integrated  Support 
Document  (CRISD) 

Planning  information  into  Software  Transition  Plan  (STrP) 
Modification  procedures  into  Software  Product  Specification 
(SPS) 

Software  Product  Specification  (SPS) 

Software  Product  Specification  (SPS) 

Software  Programmer's  Manual  (SPM) 

Computer  Programming  Manual  (CPM) 

Firmware  Support  Manual  (FSM) 

Firmware  Support  Manual  (FSM) 

Version  Description  Document  (VDD) 

Software  Version  Description  (SVD) 

FIGURE  16.  Mapping  of  DQD-STD-21  67A  DIDs  to  MIL-STD-498  DIDs. 
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MIL-STD-498  DID 

DOD  STD-2 167A  and  DOD  STD  7935A  Source  DIDs 

Software  Development  Plan  (SDP) 

2167A  Software  Development  Plan  (SDP) 

7935A  Functional  Description  (FD),  section  7 

Software  Installation  Plan  (SIP) 

7935A  Implementation  Procedures  (IP) 

Software  Transition  Plan  (STrP) 

2 167 A  Comp  Res  Integ  Sup  Doc  (CRISD)  -  planning  info 
7935A  Maintenance  Manual  (MM)  -  planning  info 

Operational  Concept  Description  (OCD) 

2167A  System/Segment  Design  Doc  (SSDD),  section  3 
7935A  Functional  Description  (FD),  section  2 

System/Subsystem  Specification  (SSS) 

2167A  System/Segment  Specification  (SSS) 

7935A  Functional  Description  (FD)  -  system  req’t  info 
7935A  System/Subsystem  Spec  (SS)  -  system  req't  info 

System/Subsystem  Design  Description  (SSDD) 

2167A  System/Segment  Design  Document  (SSDD) 

7935A  System/Subsystem  Spec  -  system  design  info 

Software  Requirements  Specification  (SRS) 

2167A  Software  Requirements  Specification  (SRS) 

7935A  Software  Unit  Specification  (US)  -  req't  info 

Interface  Requirements  Specification  (IRS) 

2167A  Interface  Requirements  Specification  (IRS) 

7935A  SW  Unit  Specification  (US)  -  interface  req't  info 

Software  Design  Description  (SDD) 

2167A  Software  Design  Document  (SDD) 

7935A  Software  Unit  Specification  (US)  -  design  info 
7935A  Maintenance  Manual  (MM)  -  "as  built"  design  info 

Interface  Design  Description  (IDD) 

2167A  Interface  Design  Document  (IDD) 

7935A  SW  Unit  Specification  (US)  -  interface  design  info 

Database  Design  Description  (DBDD) 

7935A  Database  Specification  (DS) 

Software  Test  Plan  (STP) 

2 167 A  Software  Test  Plan  (STP) 

7935A  Test  Plan  (PT)  -  high-level  information 

Software  Test  Description  (STD) 

2167A  Software  Test  Description  (STD) 

7935A  Test  Plan  (PT)  -  detailed  information 

Software  Test  Report  (STR) 

2167A  Software  Test  Report  (STR) 

7935A  Test  Analysis  Report  (RT) 

Software  Product  Specification  (SPS) 

2 167 A  Software  Product  Specification  (SPS) 

2167A  CRISD  -  modification  procedures 

7935A  MM  -  maintenance  procedures 

Software  Version  Description  (SVD) 

2167A  Version  Description  Document  (VDD) 

Software  User  Manual  (SUM) 

2 167 A  Software  User's  Manual  (SUM) 

7935A  End  User  Manual  (EM) 

Software  Center  Operator  Manual  (SCOM) 

7935A  Computer  Operation  Manual  (OM) 

Software  Input/Output  Manual  (SIOM) 

7935A  Users  Manual  (UM) 

Computer  Operation  Manual  (COM) 

2167A  Computer  System  Operator's  Manual  (CSOM) 

Computer  Programming  Manual  (CPM) 

2167A  Software  Programmer's  Manual  (SPM) 

Firmware  Support  Manual  (FSM) 

2 167 A  Firmware  Support  Manual  (FSM) 

FIGURE  17.  Mapping  of  MIL-STD-498  DIDs  to  DOD-STD-2 1  67A  and  DOD-STD-7935A  DID; 
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This  index  covers  both  MIL-STD-498  and  its  DIDs.  Paragraphs  in  the  DIDs  are  indicated  by  the  DID  acronym 
followed  by  paragraph  numbers;  an  overall  DID  is  indicated  by  the  DID  acronym  alone;  paragraphs  and  figures 
in  the  standard  have  no  preceding  acronym.  DID  references  that  begin  with  "10.1"  refer  to  paragraphs  in 
Block  10,  section  10.1  of  the  DID  (General  Instructions).  All  other  DID  references  that  do  not  cite  a  Block 
number  refer  to  paragraphs  in  Block  10,  section  10.2  of  the  DID  (Content  Requirements).  Entries  in  bold 
indicate  primary  sources  of  information  about  a  topic.  The  entry  "et  al"  indicates  that  a  topic  (such  as 
"software")  appears  too  frequently  to  cite  all  references. 


acceptance  3.1,  3.30,  E.3;  IRS  3;  SRS  3;  SSS  3 
access 

access  for  acquirer  review  4.2.7;  SDP  4.2.7 
access  to  information  in  a  repository  6.4 
acquirer  (use  of  term  "acquirer"  in  MIL-STD-498) 
Foreword-4,  1.2.1,  3.2,  Fig  14 
acquisition  strategies  (see  program  strategies) 
acronyms  Appendix  A 
allocation 

allocation  of  computer  hardware  resources  4.2.5; 

SDP  4.2.5;  SDD  4.1;  SSDD  4.1 
allocation  of  requirements  Fig  3,  Fig  6;  SDD  4.1,  6; 
SRS  5;  SSDD  4.1,  5;  SSS  5 
ANSI/IEEE/EIA  1498  Foreword-1 
application  of  MIL-STD-498  1.2 
approval  (by  the  acquirer)  3.3,  5.1.6,  5.7.1,  5.9.2, 
5.13.7,  5.18.1,  5.18.2,  5.19.7,  C.1,  D.1 
architecture  3.4  (also  see  CSCI  architectural  design, 
system  architectural  design) 

"as  built"  design  descriptions  5.13.4,  5.13.5,  Fig  2, 

Fig  3,  Fig  6,  D.4.1,  Fig  17;  SDP  5.13.4,  5.13.5; 
SPS  3,  5.1 

associate  developer  3.5,  5.19.6,  Fig  9-12;  SDP  5.19.6 
assurance  4.2.4;  SDP  4.2.4  (also  see  software 
quality  assurance) 

privacy  assurance  4.2.4.3;  SDP  4. 2. 4. 3 
safety  assurance  4.2.4.1;  SDP  4. 2. 4.1 
security  assurance  4.2.4.2;  SDP  4. 2.4. 2 
audits  (configuration  audits)  5.14.4;  SDP  5.14.4 

behavioral  design  3.6,  5.4.1,  5.6.1,  Fig  2,  Fig  3; 

DBDD  3;  OCD  3.3,  5.3,  SDD  3,  SSDD  3 
builds  3.7,  5,  Fig  1,  G.3,  G.5,  Fig  10,  Fig  11 
build  planning  guidance  G.6,  Fig  13 
notes  on  interpreting  activities  for  multiple  builds 
5.1-5.16,  5.18 

category  classifications  for  problem  reporting  5.17.2, 

Fig  2,  C.1,  C.3,  Fig  4;  SDP  5.17.2  (also  see 
corrective  action) 

code  standards  4.2.2,  D.4.7,  G.6. 2;  SDP  4.2.2; 
SF^5.3 

coding  (see  software  implementation  and  unit  testing) 
commercial  off-the-shelf  (COTS)  (see  reuse,  reusable 
software  products) 

compilers,  compilation/build  procedures  3.38,  5.13.7, 

Fig  6;  CPM  3;  SPS  5.2,  5.3;  STP  3.x. 1;  STrP  3.3 
compliance  with  the  contract  5.1.6,  5.16.3 


computer-aided  software  engineering  (CASE) 

Foreword-3,  1.2.4.4,  3.38.  5.1.1,  6.4,  Fig  2,  H.5; 
all  DIDs:  Block  7;  STrP  3.3 

computer  center,  software  center  5.12.3.2,  5.12.3.3; 
OCD  7.1;  SCOM;  SDP  5.12.3;  SIOM;  SIP  4; 
SUM 

computer  hardware  characteristics  CPM  3,  4;  FSM 

3.X.1,  3.X.4,  4.1;  SRS  3.10.1;  SSDD  4.1;  SSS 
3.10.1;  STrP  3.2 

computer  hardware  resource  utilization  4.2.5,  5.13.4, 
F.3;  OCD  8.2;  SDD  4.1;  SDP  4.2.5;  SPS  5.4, 

6;  SRS  3.10.2;  SSDD  4.1;  SSS  3.10.2 

Computer  Operation  Manual  (COM)  5.12.3.4,  6.2, 

Fig  4,  Fig  6,  E.4.9,  Fig  9-12,  Fig  16,  Fig  17; 

COM;  SDP  5.12.3 

computer  program  3.10 

Computer  Programming  Manual  (CPM)  5.13.6.1,  6.2, 

Fig  6,  Fig  9-12,  Fig  16,  Fig  17;  CPM;  SDP 
5.13.6 

Computer  Software  Configuration  Item  (CSCI)  1.2.2, 
3.12,  3.24,  Fig  14,  et  al 
CSCI  architectural  design  3.4,  5.6.2,  Fig  3, 

Fig  6,  E.4.6;  SDD  4;  SDP  5.6.2;  SPS  5.1 
CSCI  detailed  design  3.45,  5.6.3,  5.13.4,  Fig  3, 

Fig  6,  E.4.6;  SDD  5;  SDP  5.6.3,  5.13.4;  SPS 
5.1  (also  see  Database  Design  Description, 
Interface  Design  Description) 

CSCI/HWCI  integration  and  testing  4.1,  Fig  1,  5.10, 
Fig  3,  Fig  6,  Fig  9-12;  SDP  5.10 
CSCI  qualification  testing  3.28,  3.43,  4.1,  Fig  1, 
5.1.2,  5.2.2,  5.9,  5.9.5,  Fig  3,  Fig  6,  E.4.7, 
E.4.8,  Fig  9-13;  IRS  4;  SDP  5.1.2,  5.9; 

SRS  4,  STD;  STP;  STR 
CSCI  requirements  5.5,  5.6.2,  5.7,  5.9,  5.9.3, 

Fig  2-4,  Fig  6,  Fig  9-12;  DBDD  3,  4,  6;  IDD 
4;  SDD  4.1,  5,  6;  SDP  5.5;  SPS  5.4,  6;  SRS 
3;  STD  4.x.y.1,  5;  STP  6  (also  see  software 
requirements  analysis,  Software  Requirements 
Specification,  Interface  Requirements 
Specification) 

CSCI-wide  design  decisions  3.6,  5.6.1,  Fig  3, 

Fig  6,  E.4.6;  SDD  3,  4.1;  SDP  5.6.1,  5.13.4; 
SPS  5.1 

configuration  management  (see  software  configuration 
management) 

Continuous  acquisition  and  life-cycle  support  (CALS) 

Fig  2;  all  DIDs:  Block  7 
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contract,  contract-specific  application  1.2.2 
use  of  term  “contract"  in  MIL-STD-498 
Foreword-4,  1.2.1 

references  to  the  contract  Foreword-4,  Foreword-5, 

1.2.1,  1.2.2,  1. 2.4.1,  3.1,  3.3,  3.16,  3.18, 
3.26,  3.30,  3.39,  4.1,  4. 2.3.1,  4. 2. 3.2, 

4. 2. 4. 4,  4.2.5,  4.2.7,  5.1,  5.1.1,  5. 1.4-5. 1.6, 

5.2.3,  5.2.4,  5.4.1,  5.7.1,  5.12.4,  5.13.7, 
5.14.1-5.14.5,  5.15.2,  5.16.1-5.16.3,  5.17.1, 

5.17.2,  5.19.3-5.19.6,  6.2,  6.4,  6.5,  B.3, 

G.6,  G.6.3;  all  DIDs:  Block  7  (7.1),  10.1. c, 

10.1,  h;  SDP  4.1,  4.2.1,  4.2.2,  4.2. 3.1, 

4. 2. 3. 2,  4. 2. 4-4. 2. 7,  5.1-5.19;  SRS  3.11; 
SSS3.16;  STrP  7 

Contract  Data  Requirements  List  (CDRL)  1.2.1,  5.1.1, 

6.3,  6.4,  6.5,  Fig  6,  D.4.9,  H.4,  H.5,  H.6; 
all  DIDs:  Block  7,  10.1.C 
contracting  agency  (see  acquirer) 
contractor  (see  developer) 
conversion  guide  from  DOD-STD-2167A  and 
DOD-STD-7935A  Appendix  I 
corrective  action,  corrective  action  system  4.1, 

Fig  1,  5.17,  Fig  3,  Appendix  C,  Fig  9-12; 

SDP  5.17  (also  see  problem  reporting) 

cost 

cost  benefit,  cost-effectiveness  Foreword-9, 

4.2. 3. 2,  6.5,  B.3 

cost/schedule  reporting,  cost/schedule  risks 

5.18.1,  5.18.2,  5.19.1,  6.6,  B.3,  Fig  5 
critical  requirements  4.2.4,  Fig  5;  DBDD  3;  IRS  3.y; 

SDD  3;  SDP  4.2.4;  SRS  3.18;  SSDD  3;  SSS  3.18 
critical  requirements  reviews  E.4.11 
privacy  assurance  4.2.4.3,  5.19.3,  B.3,  E.4.11 
safety  assurance  4.2.4. 1,  Fig  2,  B.3,  Fig  5,  E.4.1 1 
security  assurance  4.2.4.2,  5.19.3,  Fig  2,  B.3, 

Fig  5,  E.4.11 

data  elements/data  element  assemblies  all  DIDs:  lO.I.h; 
DBDD  3,  4.x,  5.x;  IDD  3.x;  IRS  3.x;  SDD  3, 

4.3.x,  5.x;  SIOM  5.1;  SRS  3.2.x,  3.3.x,  3.4, 

3.5;  SSDD  3.  4.3.x;  SSS  3.2.x,  3.3.x,  3.4,  3.5 
data  rights  4.2. 3.1,  B.3;  STP  3.X.4;  STrP  3.2,  3.3, 

3.4  (also  see  licenses,  licensing) 
data  standardization,  standard  data  descriptions 
all  DIDs:  lO.I.h 

Data  Item  Description  (DID)  Foreword-9,  1.2.3,  5'.  1.1, 
5.13.6,  6.2,  6.3,  6.4,  6.5,  D.4.4,  G.5,  Appendix 

H,  1.4,  Fig  15-17 

database  3.14,  3.15,  3.32,  3.45,  5.7.1,  5.12.1, 

5.13.1,  5.13.2,  6.4,  Fig  4;  SCOM  3.2,  3.3, 

5. 5.x. 3;  SIOM  3.2,  3.4,  5.1;  SIP  4.x. 5;  SPS 

3.1,  3.2;  SRS  3.5,  3.10.3,  3.12;  SSS  3.5, 

3.10.3;  STD  4.x.y.6;  STP  3.x. 1;  SUM  3.2,  3.3 

database  design.  Database  Design  Description  (DBDD) 

5.4.1,  5.6.1,  5.6.3,  6.2,  Fig  9-12,  Fig  15,  Fig  17; 
DBDD;  SDD  3,  4.1,  5,  5.x,  6;  SPS  5.1,  5.3; 

SSDD  3,  4.1 

define  (interpretation  of  “define"  in  MIL-STD-498) 

I.  2.4.3 


definitions  of  software  product  evaluation  criteria  D.4 
definitions  of  terms  3 

deliverables,  deliverable  software  products  1.2.1,  1.2.2, 
3.16,  5.1.1  Notes  1-2,  5.2.5,  5.13.7,  5.14.5, 
5.15.1;  all  DIDs:  Block  7 

guidance  on  ordering  deliverables  6.5,  Appendix  H 
design  3.17  (also  see  "as  built"  design  descriptions, 
behavioral  design,  CSCI  architectural  design,  CSCI 
detailed  design,  CSCI-wide  design  decisions, 
Database  Design  Description,  Interface  Design 
Description,  software  design,  Software  Design 
Description,  system  architectural  design, 
System/Subsystem  Design  Description,  system- 
wide  design  decisions) 

design  standards  4.2.2,  D.4. 7;  DBDD  3,  4,  5;  IDD  3; 

SDD  3,  4,  5;  SDP  4.2.2;  SPS  5.3;  SSDD  3,  4 
detailed  requirements  of  MIL-STD-498  5 
develop  (interpretation  of  "develop"  in  MIL-STD-498) 

1. 2.4.3 

developer  (use  of  term  "developer"  in  MIL-STD-498) 
Foreword-4,  1.2.1,  3.18,  Fig  14 
documentation  Foreword-3,3.19,5.1.1;  all  DIDs: 

Block  7,  10.1. a,  lO.I.i  (also  see  Data  Item 
Description) 

DOD-STD-1 703  Foreword-3 
DOD-STD-2 1 67  A  Foreword-3 

mapping  between  MIL-STD-498  DIDs  and 

DOD-STD-2 167 A  DIDS  1.4,  Fig  16,  Fig  17 
mapping  of  key  MIL-STD-498  terms  to 
MIL-STD-2167A  1.3,  Fig  14 
DOD-STD-7935A  Foreword-3 

mapping  between  MIL-STD-498  DIDs  and 

DOD-STD-7935A  DIDs  1.4,  Fig  15,  Fig  17 
mapping  of  key  MIL-STD-498  terms  to 
MIL-STD-7935A  1.3,  Fig  14 
dry  run  of  qualification  tests  5.9.4,  5.11.4,  Fig  6, 

D.4.2;  SDP  5.9.4,  5.11.4 

error  reporting  (see  problem  reporting) 
evaluation  3.20  (also  see  Independent  Verification  and 
Validation,  reusable  software  products,  software 
product  evaluations,  software  quality  assurance, 
test  case  evaluation  criteria) 

Evolutionary  program  strategy  Foreword-3,  G.3,  Fig  7, 

Fig  8,  Fig  1 1 

executable  software  Fig  6 

compilation/build  procedures  Fig  6;  SPS  5.2,  5.3 
delivery  of  executable  software  SPS  3.1 
incorporating  reusable  software  into  the  executable 
software  Fig  3 

installing  executable  software  5.12.4 
preparing  the  executable  software  for  software 
transition  5.13.1;  SDP  5.13.1 
preparing  the  executable  software  for  software  use 
5.12.1;  SDP  5.12.1 

regenerating  executable  software  5.13.2,  5.13.7; 

SPS  3.2 

version  descriptions  (see  Software  Version 
Description) 
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firmware  1.2.2,3.21,3.38.3.43;  SPS  5.2;  STP  3.x. 2 
Firmware  Support  Manual  (FSM)  5.13.6.2,  6.2,  Fig  6, 
Fig  9-12,  Fig  16,  Fig  17;  FSM;  SDP  5.13.6 
^forward  engineering  3.29,  Fig  12 


general  requirements  of  MIL-STD-498  4 
Government  in-house  agencies  {as  developers) 
Foreword-4,  1.2.1 

Grand  Design  program  strategy  G.3,  Fig  7,  Fig  8,  Fig  9 


Hardware  Configuration  Item  (HWCI)  3.22,  3.24,  5.10; 
SDP  5.10;  SRS  3.10.1;  SSDD4,  4.1;  SSS 
3.10.1 

hardware-software  systems  1. 2.4.1,  1.2. 4. 2,  Fig  14; 
SSDD  3;  SSS  3.9,  3.10,  3.12 


implementation  (see  software  implementation  and  unit 
testing) 

Incremental  program  strategy  Foreword  3,  G.3,  Fig  7, 
Fig  8,  Fig  10 
in-process 

in-process  and  final  software  product  evaluations 
5.15.1;  SDP  5.15.1 

joint  reviews  of  in-process  and  final  software 
products  5.18.1 
independence 

independence  in  software  product  evaluation 
5.15.3;  SDP  5.15.3 

independence  in  software  quality  assurance  5.16.3; 
SDP  5.16.3 

independence  in  qualification  testing  5.9.1,  5.11.1; 
SDP  5.9.1,  5.11.1 
Independent  Verification  and  Validation  (IV&V)  3.23, 
5.19.5,  Fig  9-12;  SDP  5.19.5 
installation 

installation  at  the  support  site  5.13.7;  STrP  7 
installation  at  user  sites  5.12.4,  Fig  6,  E.4.9,  Fig  14; 
SCOM  4;  SDP  5.12.4;  SIP;  SSS  3.16;  SUM 
4.1.3;  SVD  3.6 

software  installation  planning  5.1.4,  6.2,  Fig  6, 
E.4.1,  Fig  9-13,  Fig  15.  Fig  17;  SDP  5.1.4; 

SIP 

integral  software  development  processes  4.1 
integration  (see  CSCI/HWCI  integration  and  testing,  unit 
integration  and  testing) 
interface  3.24 

interface  design,  Interface  Design  Description  (IDD) 

5.4.1,  5.4.2.  5.6.1,  5.6.2,  5.6.3,  6.2,  Fig  6, 
Fig  9-12,  Fig  15-17;  DBDD  3,  5.x;  IDD;  SDD 
3,  4.3,  5,  5.x,  6;  SPS  5.1;  SSDD  3.  4.3,  5 
interface  requirements,  Interface  Requirements 

Specification  (IRS)  5.3.3,  5.5,  5.9,  5.11,  6.2, 
Fig  6,  Fig  9-12,  Fig  15-17;  IRS;  SRS  3.3,  3.4; 
SSS  3.3,  3.4;  STD  5;  STP  6 
ISO/IEC  DIS  12207  Foreword-6 


joint  technical  and  management  reviews  3.25,  4.1,  Fig  1 
5.18,  Fig  2-3,  Fig  9-12,  G.6.3,  H.3;  SDP  5.18 
candidate  joint  management  reviews  Appendix  E 


key  decisions  (recording  rationale  for  key  decisions) 

3.34,  4.2.6,  5.2.4;  all  DIDs:  Notes  section; 

SDP  4.2.6 

key  word  listing  in  MIL-STD-498  6.8 
key  terms  (mapping  of  key  MIL-STD-498  terms  to 
DOD-STD-21 67A,  DOD-STD-7935A)  1.3, 

Fig  14 

licenses,  licensing  B.3,  Fig  3;  STP  3.x. 4;  STrP  3.2, 

3.3,  3.4  (also  see  data  rights) 

life  cycle  Foreword-4,  Fig  2,  Fig  5,  G.2;  SDP  3 
logistics  SRS  3.15;  SSS  3.15  (also  see  Continuous 
acquisition  and  life-cycle  support  (CALS)) 

maintenance  Foreword-4,  1.2.1,  1.2. 4. 3,  3.33,  3.41, 

Fig  14  (also  see  software  support) 
management  indicators  (see  software  management 
indicators) 

management  review  5.1.6;  SDP  5.1.6 
metrics  (see  software  management  indicators) 

non-deliverable  software  products  1.2.2,3.26,5.2.5; 
SDP  5.2.5 

Notes  6;  all  DIDs:  Notes  section 

operational  concept.  Operational  Concept  Description 
(OCD)  5.3.2,  6.2,  Fig  3,  Fig  4,  Fig  6,  E.4.2. 

Fig  9-12,  Fig  15-17;  OCD;  SDP  5.3.2 
operational  concept  reviews  E.4.2 

packaging,  packaging  requirements  5.14.5;  SDP 

5.14.5;  SPS  3.3;  SRS  3.17;  SSS  3.17;  STrP  7 
participate  (interpretation  of  "participate’  in 
MIL-STD-498)  1. 2.4.2 

participation  in  system-level  activities  5.1.3,  5.3, 

5.4,  5.10,  5.1 1,  5.13.5,  D.3;  SDP  5.3,  5.4, 
5.10,  5.11 

planning  (see  build  planning,  project  planning,  software 
development  planning,  software  installation 
planning,  software  transition  planning,  test 
planning) 

priority  classifications  for  problem  reporting  5.17.2, 

C.1,  C.4,  Fig  5,  F.3  (also  see  corrective  action) 
privacy  4. 2.4. 3,  5.19.3,  B.3,  E.4.1 1,  Fig  9-12; 

all  DIDs  1.3;  COM  3.2.4;  DBDD  3,  4.x,  5.x; 

FSM  3.x. 5;  IDD  3.x;  IRS  3.x,  3.y;  OCD  3.3,  5.3; 
SCOM  3.2,  3.4,  3.6,  5.5.x;  SDD  3,  4.3.x;  SDP 
3,  4.2.4. 3,  5.19.3;  SIOM  3.2,  3.4,  3.6,  4.2.1, 

4.3.1,  4.3.2;  SIP  3.7,  SRS  3.3.x,  3.8,  3.18; 
SSDD  3,  4.3.x;  SSS  3.3.x,  3.8,  3.18;  STD  3.  4; 
STP  3.x. 1,  3.x. 2,  3.x. 3,  4.2.x.y;  STrP  3. 1-3.4; 
SUM  3.2,  3.4,  3.6,  4.1.2;  SVD  3.1,  3.2,  3.6 
(also  see  assurance) 

problem  reporting,  problem/change  reports  5.3.1, 

5.14.3,  5.15.2,  5.16.2,  5.17.1,  5.17.2,  Fig  2, 
Appendix  C,  Fig  4,  Fig  5,  F.3;  SDP  5.17.1;  STR 

3.1,  4.x. 2.y;  SVD  3.3,  3.7 

process  improvement  5.19.7,  Fig  9-1 2;  SDP  5.19.7 
program  (computer  program)  3.10 
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program  strategies  Appendix  G,  Fig  7,  Fig  8, 

Fig  9-11,  H.4;  SDP  3 

programming  languages  3.29,  4.2.2,  5.7.1,  Fig  2; 
DBDD  5.X;  SDD  5.x;  SDP  4.2.2;  SRS  3.12; 

SSS  3.12  (also  see  Computer  Programming 
Manual) 

project  planning  4.1,  Fig  1,  5.1,  Fig  3,  Fig  6, 

Fig  9-13;  SDP  1.4,  5.1;  SIP  1.4;  STP  1.4; 

STrP  1.4  (also  see  software  development 
planning) 

project-unique  identifiers  5.14.1;  DBDD  3,  4, 

4.x,  5,  5.x;  IDD  3,  3.1,  3.x;  IRS  3,  3.1, 

3. x;  SDD  3,  4,  4.1,  4.3.1, 4.3.x,  5,  5.x; 

SRS  3,  3.3.1,  3.3.x;  SSDD  3,  4,  4.1,  4.3.1, 

4.3.x;  SSS  3,  3.3.1,  3.3.x;  STD  3.x,  4.x, 

4. x.y;  STP  4.2.x,  4.2.x.y;  STR  4.x,  4.x. 2.y, 
4.x.3.y 

prototypes  5.3.1,  G.6.1,  Fig  11,  Fig  13 

qualification  methods  IRS  3,  4;  SPS  4;  SRS  3,  4; 

SSS  3,  4;  STP  4.2.x.y 

qualification  testing  3.28,  3.43,  5.2.2,  5.4.1,  5.9,  5.11 
(also  see  CSCI  qualification  testing,  system 
qualification  testing) 

quality  assurance  (see  software  quality  assurance) 
quality  factors  (reliability,  maintainability,  etc.) 

B.3;  DBDD  3;  OCD  3.3,  5.3;  SDD  3;  SRS  3.11; 
SSDD  3;  SSS  3.11 

rationale  (recording  rationale)  3.34,  4.2.6,  5.2.4; 

all  DIDs:  Notes  section;  SDP  4.2.6 
record  (interpretation  of  "record"  in  MIL-STD-498) 

1. 2.4.4 

redocumentation  3.29,  Fig  12 

reengineering  Foreword-4,  1.2.1,  1.2. 4. 3,  3.29,  3.33, 
G. 5,  Fig  12;  SDD  4.1;  SSDD  4.1 
requirement  (definition  of  requirement)  3.30 
requirements  analysis  (see  software  requirements 
analysis,  system  requirements  analysis, 
traceability) 

resource  utilization  (see  computer  hardware  resource 
utilization) 

restructuring  3.29,  Fig  1 2 
retargeting  3.29,  Fig  1 2 

reuse,  reusable  software  products  Foreword-4,  1.2.1, 

1 .2.4.3,  3.31,  3.33,  4.2.3;  SDP  4.2.3 
developing  reusable  software  products  4.2. 3.2; 

SDP  4. 2. 3.2;  SDD  4.1;  SSDD  4.1 
evaluating  reusable  software  products  4. 2. 3.1, 

B.3;  SDP  4. 2. 3.1 

incorporating  reusable  software  products 

Foreword-3,  3.12,  4.2. 3.1,  Appendix  B,  Fig  3; 
all  DIDs:  10.1. i;  SDP  4. 2. 3.1;  SDD4.1; 

SSDD  4.1 

reverse  engineering  3.29,  Fig  1 2 

reviews  (see  joint  technical  and  management  reviews) 

revision  and  retesting  5.7.4,  5.8.3,  5.9.6,  5.10.3, 

5.11.6;  SDP  5.7.4,  5.8.3,  5.9.6,  5.10.3,  5.11.6; 
STD  4.x. y,  4.x.y.3,  5;  STP  4.1.3,  5 


risk  management  5.18.1,  5.18.2,  5.19.1,  B.3,  Fig  5, 
G.4,  Fig  8-12;  SDP  4,  5,  5.19.1 

safety  4.2.4.1,  Fig  2,  B.3,  Fig  5,  E.4.1 1;  COM3; 

DBDD  3,  5.x;  FSM  3.x. 6;  IDD  3.x;  IRS  3.x,  3.y; 
OCD  3.3,  5.3;  SCOM  4,  5;  SDD  3,  4.3.x;  SDP 
4.2. 4.1;  SIOM  4,  6;  SIP  4.x. 5,  5.x. 2;  SRS 

3.3. x,  3.7,  3.18;  SSDD  3,  4.3.x;  SSS  3.3.x,  3.7, 
3.18;  STD  3,  4;  STP  4.2.x.y;  STrP  3.1;  SUM  4, 
5;  SVD  3.6  (also  see  assurance) 

schedules  3.34;  SDP  3,  6,  7.2;  SIP  3.1,  4.X.1,  5.x. 1; 
STP  5;  STrP  5,  7 

cost/schedule  reporting,  cost/schedule  risks 
5.18.1,  5.18.2,  5.19.1,  6.6,  B.3,  Fig  5 
guidance  on  scheduling  activities  G.6.4 
guidance  on  scheduling  deliverables  H.4 
scope  of  MIL-STD-498  1 

security  4. 2.4.2,  5.19.3,  Fig  2,  B.3,  Fig  5,  E.4.1 1, 

Fig  9-12;  all  DIDs  lO.I.c,  1.3;  COM  3.2.4; 

DBDD  3,  4.x,  5.x;  FSM  3.x. 5;  IDD  3.x;  IRS  3.x, 
3.y;  OCD  3.3,  5.3;  SCOM  3.3,  3.4.1,  3.4.2, 

3.7,  5.5.x;  SDD  3.  4.3.x;  SDP  3,  4.2.4.2, 

5.19.3,  7.2;  SIOM  3.2,  3.4,  3.6,  4.2.1,  4.3.1, 
4.3.2;  SIP  3.7,  4.x. 2;  SRS  3.3.x,  3.8,  3.18; 
SSDD  3,  4.3.x;  SSS  3.3.x,  3.8,  3.18;  STD  3,  4; 
STP  3.x. 1,  3.x. 2,  3.x. 3,  4.2.x.y;  STrP  3. 1-3.5; 
SUM  3.2,  3.4,  3.6,  4.1.2;  SVD  3.1,  3.2,  3.6 
(also  see  assurance) 

software  3.32,  et  al 

Software  Center  Operator  Manual  (SCOM)  5-12.3.3, 

6.2,  Fig  6,  Fig  9-12,  Fig  15,  Fig  17;  SCOM  (also 
see  Software  Input/Output  Manual,  Software  User 
Manual) 

software  configuration  management  3.12,  4.1,  Fig  1, 
5.14,  Fig  2,  Fig  3,  Fig  9-12;  SDP  5.14 
configuration  audits  5.14.4;  SDP  5.14.4 
configuration  control,  author  control,  project-level 
control,  acquirer  control  5.14.1,  5.14.2, 

5.14.3,  5.15.2,  5.16.2,  5.17.1,  5.17.2,  F.3; 
SDP  5.14.2 

configuration  identification  5.14.1;  SDP  5.14.1 
configuration  status  accounting  5.14.3;  SDP  5.14.3 
packaging,  storage,  handling,  and  delivery  (of 

software  products)  5.14.5;  SDP  5.14.5 
software  design,  Software  Design  Description  (SDD) 

3.17,  3.39,  3.45,  4.1,  4.2.6,  Fig  1,  5.2.4,  5.6, 

5.7,  5.9.1,  5.11.1,  6.2,  Fig  2,  Fig  4,  Fig  6,  F.3, 

Fig  9-12,  Fig  15-17;  DBDD  5;  SDD;  SDP  5.6; 

SPS  5.1  (also  see  "as  built"  design  descriptions, 
behavioral  design,  CSCI  architectural  design,  CSCI 
detailed  design,  CSCI-wide  design  decisions, 
Database  Design  Description,  Interface  Design 
Description,  system  architectural  design, 
System/Subsystem  Design  Description,  system- 
wide  design  decisions) 
software  design  reviews  E.4.6 
software  design  standards  4.2.2,  D.4.7;  DBDD  3, 

4,  5;  IDD  3;  SDD  3,  4,  5;  SDP  4.2.2;  SPS 
5.3;  SSDD  3,  4 
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software  development  (meaning  of  term  "software 
development"  in  MIL-STD-498)  Foreword-4, 

|  1.2.1,3.33 

W  software  development  environment  1.2.2,  4.1,  Fig  1, 

5.2,  5.14.1,  Fig  2,  Fig  3,  E.4.10,  Fig  9-13; 

SDP  5.2  (also  see  software  engineering 
environment,  testing  -  software  test  environment) 
software  development  files  (SDF)  3.34,  5.2.4,  5.7.2, 
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SDP  5.15 

independence  in  software  product  evaluation 
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in-process  and  final  software  product  evaluations 
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Fig  6,  D.4;  SDP  5.15.1 
software  product  evaluation  records  5.15.2; 
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Fig  3,  Fig  9-12;  SDP  5.5 
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5.2.3,  5.2.5,  5.13.4,  Fig  2,  Fig  3,  Fig  6,  Fig  14; 
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support  manuals  5.13.6,  Fig  4,  Fig  6,  E.4.10; 
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support  site  5.13.1-5.13.3,5.13.7;  SDP  5.13.3, 
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software  testing  (see  testing) 
software  transition  3.44 
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(STrP)  Fig  1,  5.1.5,  6.2,  Fig  4,  Fig  6,  E.4.1, 
Fig  9-12,  Fig  15-17;  SDP  5.1.5;  STrP 
software  transition  (preparing  for)  4.1,  Fig  1,  5.13, 

Fig  3,  Fig  9-12;  SDP  5.13 

software  unit  3.24,  3.45,  5.2.4,  5.6,  5.7,  5.8,  5.13.4, 

5.14.1,  B  4,  Fig  3,  Fig  6,  F.3,  G.6.4,  Fig  14, 

Fig  15,  Fig  17;  DBDD  5,  5.x,  6;  SDD  3,  4.1,  4.2, 

4.3,  4.3.1,  5,  5.x,  6;  SPS  5.4,  6;  SRS  3.12 
(also  see  testing) 

software  use  (preparing  for)  4.1,  Fig  1,  5.12,  Fig  3, 

Fig  9-12 

software  usability  reviews  E.4.9 
Software  User  Manual  (SUM)  5.12.3,  5.12.3.1,  6.2, 

Fig  2,  Fig  3,  Fig  4,  Fig  6,  E.4.9,  Fig  9-12,  Fig  15- 
17;  SDP  5.12.3;  SIP  3.5,  4.x.6,  5.X.2,  5.x. 3; 
STrP  3. 2-3. 4;  SUM  (also  see  Software  Center 
Operator  Manual,  Software  Input/Output  Manual) 
Software  Version  Description  (SVD)  5.12.2,  5.13.3, 

6.2,  Fig  3,  Fig  6,  D.4.1,  E.4.9,  E.4.10,  Fig  9-12, 
Fig  16,  Fig  17;  SDP  5.12.2,  5.13.3;  SVD  (also 
see  version/revision/release! 

source  code,  source  files  3.29,  5.7.1,  5.12.1,  5.13.2, 
5.13.4,  B.3,  Fig  3,  Fig  4,  Fig  6,  F.3;  SDP  5.7.1, 
5.13.2;  SPS  3.2,  3.3,  5.1;  SVD  3.2 
delivery  of  source  files  SPS  3.2 
staffing  F.3,  Fig  8;  OCD  3.4,  5.4,  7.2;  SDP  7; 

SIP  3.5,  3.6,  4.x. 4;  STP  3.x. 6,  3.x.7;  STrP  3.5 
standardization  documents  related  to  MIL-STD-498  Fig  2 
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1.2.1,  3.5,  4.2.7,  5.4.1,  5.19.4;  SDP  4.2.7, 
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transition  planning) 

system  (also  see  operational  concept) 

interpretation  of  "system"  in  MIL-STD-498  1. 2.4.1, 
Fig  14 

system  architectural  design  3.4,  5.4.2,  Fig  3,  Fig  4, 
Fig  6,  E.4.4;  SDP  5.4.2,  5.1 3.5;  SSDD  4 
system  design  3.17,  4.1,  Fig  1,  5.4,  5.13.5,  Fig  3, 
Fig  4,  E.4.4,  Fig  9-12;  SDP  5.4,  5.13.5 
system  qualification  testing  3.28,  3.43,  4.1,  Fig  1, 

5.1.3,  5.2.2,  5.11,  5.11.5,  Fig  3,  Fig  6,  E.4.7, 

E.4.8,  Fig  9-13;  IRS  4;  SDP  5.11;  SSS  4; 
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system  requirements  5.3.3,  5.4.2,  5.5,  5.11.3,  Fig  3, 
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Fig  9-12;  SDP  5.3 
system  test  planning  5.1.3;  STP 
system-wide  design  decisions  3.6,  5.4.1,  5.10.1, 

Fig  3,  Fig  6,  E.4.4;  SDP  5.4.1;  SSDD  3,  4.1 
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5.4.1,  5.4.2,  5.13.5,  5.13.6,  6.2,  Fig  6, 

Fig  9-12,  Fig  15-17;  SSDD 
system/subsystem  design  reviews  E.4.4 
system/subsystem  requirements  reviews  E.4.3 
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6.2,  Fig  6,  Fig  9-12,  Fig  15-17;  SSS 
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testing  Fig  2,  D.4.13;  STD;  STP;  STR 

advance  notice  of  qualification  testing  5.9.3,  5.9.6, 

5.11.3,  5.11.6 

CSCI/HWCI  integration  and  testing  4.1,  Fig  1, 5.10, 
Fig  3,  Fig  6,  Fig  9-12;  SDP  5.10 
CSCI  qualification  testing  3.28,  3.43,  4.1,  Fig  1, 

5.1.2,  5.2.2,  5.9,  5.9.5,  Fig  3,  Fig  6,  E.4.7, 
E.4.8,  Fig  9-13;  IRS  4;  SDP  5.1.2,  5.9; 

SRS  4;  STD;  STP;  STR 


developer-internal  testing  3.34,  5.4.1,  5.8,  5.9, 
5.10,  5.11;  SDP  5.9.4,  5.11.4 
dry  run  of  qualification  testing  5.9.4,  5.11.4,  Fig  6, 

D. 4.2 

revision  and  retesting  5.7.4,  5.8.3,  5.9.6,  5.10.3, 
5.11.6;  SDP  5.7.4,  5.8.3,  5.9.6,  5.10.3, 
5.11.6;  STD  4.x.y.3,  4.x.y.5;  STP  4.1.3,  5 
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Fig  2,  Fig  4,  Fig  6,  D.4.2,  E.4.7,  Fig  9-12, 

Fig  15-17;  STD 

software  test  environment  1.2.2,  3.37,  3.43,  4.2.7, 

5.2.2,  Fig  3,  E.4.7,  Fig  13;  SDP  5.2.2;  STP 
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software  test  planning,  Software  Test  Plan  (STP) 

5.1.2,  5.1.3,  6.2.  Fig  4,  Fig  6,  E.4.1,  Fig  9-12, 
Fig  15-17;  SDP  5.1 .2,  5.1 .3;  STP 

Software  Test  Report  (STR)  5.9.7,  5.11.7,  6.2, 

Fig  4,  Fig  6,  D.4.2,  E.4.8,  Fig  9-12,  Fig  15-17; 
SDP  5.9.7,  5.11.7;  STR 

system  qualification  testing  3.28,  3.43,  4.1,  Fig  1, 

5.1.3,  5.2.2,  5.11,  5.11.5,  Fig  3,  Fig  6,  E.4.7, 

E. 4.8,  Fig  9-13;  IRS  4;  SDP  5.11;  SSS  4; 
STD;  STP;  STR 

target  computer  system  (testing  on)  5.9.2,  5.11.2; 
SDP  5.9.2,  5.11.2 

test  classes  (timing,  erroneous  input,  maximum 
capacity)  STP  4.1 .2,  4.2.x. y 
test  information  for  developer-internal  testing  (test 
cases,  test  descriptions,  test  procedures, 
test  results)  3.34,  3.39,  5.2.4,  5.7.2,  5.8.1, 
5.10.1,  Fig  2-4,  Fig  6,  D.4.2 
test  readiness  reviews  E.4.7 
test  results  reviews  E.4.8 
unit  testing  5.7,  Fig  3,  F.3,  Fig  9-12;  SDP  5.7 
unit  integration  and  testing  4.1,  Fig  1, 5.8,  Fig  3, 

F. 3,  Fig  9-12;  SDP  5.8 
witnessed  testing  5.9.4,5.11.4;  STR  5 

traceability  5.4.2,  5.5,  5.6.2,  5.9.3,  5.1 1.3,  5.13.4; 
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3.3.1,3.10.3;  STR  5;  STrP  3. 2-3.4;  SVD 

Work  Breakdown  Structure  (WBS)  6.6,  Fig  2 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  oaae  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Paoe  numberina/labelinci.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existina  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS--  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1 . 1  Identification.  This  paragraph  shall  contain  the  manufacturer's  name,  model  number,  and 
any  other  identifying  information  for  the  computer  system  to  which  this  COM  applies. 

1 .2  Computer  system  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the 
computer  system  to  which  this  COM  applies. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Computer  system  operation.  This  section  shall  be  divided  into  the  following  paragraphs. 
Safety  precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included  where  applicable. 

3.1  Computer  system  preparation  and  shutdown.  This  paragraph  shall  be  divided  into  the 
following  subparagraphs. 

3.1.1  Power  on  and  off.  This  paragraph  shall  contain  the  procedures  necessary  to 
power-on  and  power-off  the  computer  system. 

3.1.2  Initiation.  This  paragraph  shall  contain  the  procedures  necessary  to  initiate  operation 
of  the  computer  system,  including,  as  applicable,  equipment  setup,  pre-operation, 
bootstrapping,  and  commands  typically  used  during  computer  system  initiation. 

3.1.3  Shutdown.  This  paragraph  shall  contain  the  procedures  necessary  to  terminate 
computer  system  operation. 

3.2  Operating  procedures.  This  paragraph  shall  be  divided  into  the  following  subparagraphs. 
If  more  than  one  mode  of  operation  is  available,  instructions  for  each  mode  shall  be  provided. 

3.2.1  Input  and  output  procedures.  This  paragraph  shall  describe  the  input  and  output 
media  (e.g.,  magnetic  disk,  tape)  relevant  to  the  computer  system,  state  the  procedures  to 
read  and  write  on  these  media,  briefly  describe  the  operating  system  control  language,  and 
list  procedures  for  interactive  messages  and  replies  (e.g,  terminals  to  use,  passwords,  keys). 

3.2.2  Monitoring  procedures.  This  paragraph  shall  contain  the  procedures  to  be  followed 
for  monitoring  the  computer  system  in  operation.  It  shall  describe  available  indicators, 
interpretation  of  those  indicators,  and  routine  and  special  monitoring  procedures  to  be 
followed. 


3.2.3  Off-line  procedures.  This  paragraph  shall  contain  the  procedures  necessary  to  operate 
all  relevant  off-line  equipment  of  the  computer  system. 


Computer  Operation  Manual  (COM) 

DI-IPSC-81446 

10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

3.2.4  Other  procedures.  This  paragraph  shall  contain  any  additional  procedures  to  be 
followed  by  the  operator  (e.g.,  computer  system  alarms,  computer  system  security  or  privacy 
considerations,  switch  over  to  a  redundant  computer  system,  or  other  measures  to  ensure 
continuity  of  operations  in  the  event  of  emergencies). 

3.3  Problem-handling  procedures.  This  paragraph  shall  identify  problems  that  may  occur  in 
any  step  of  operation  described  in  the  preceding  paragraphs  in  Section  3.  It  shall  state  the 
error  messages  or  other  indications  accompanying  those  problems  and  shall  describe  the 
automatic  and  manual  procedures  to  be  followed  for  each  occurrence,  including,  as  applicable, 
evaluation  techniques,  conditions  requiring  computer  system  shutdown,  procedures  for  on-line 
intervention  or  abort,  steps  to  be  taken  to  restart  computer  system  operation  after  an  abort 
or  interruption  of  operation,  and  procedures  for  recording  information  concerning  a 
malfunction. 

4.  Diagnostic  features.  This  section  shall  be  divided  into  the  following  paragraphs  to 
describe  diagnostics  that  may  be  performed  to  identify  and  troubleshoot  malfunctions  in  the 
computer  system. 

4.1  Diagnostic  features  summary.  This  paragraph  shall  summarize  the  diagnostic  features 
of  the  computer  system,  including  error  message  syntax  and  hierarchy  for  fault  isolation.  This 
paragraph  shall  describe  the  purpose  of  each  diagnostic  feature. 

4.2  Diagnostic  procedures.  This  paragraph  shall  be  divided  into  subparagraphs  as  needed  to 
describe  the  diagnostic  procedures  to  be  followed  for  the  computer  system,  including: 

a.  Identification  of  hardware,  software,  or  firmware  necessary  for  executing  each 
procedure 

b.  Step-by-step  instructions  for  executing  each  procedure 

c.  Diagnostic  messages  and  the  corresponding  required  action 

4.3  Diagnostic  tools.  This  paragraph  shall  be  divided  into  subparagraphs  as  needed  to 
describe  the  diagnostics  tools  available  for  the  computer  system.  These  tools  may  be 
hardware,  software,  or  firmware.  This  paragraph  shall  identify  each  tool  by  name  and  number 
and  shall  describe  the  tool  and  its  application. 

5.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this  docu¬ 
ment  and  a  list  of  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 


DATA  ITEM  DESCRIPTION 


Form  Approved 
OMB  NO. 0704-01 88 


Public  reporting  burdan  collection  of  tht*  informotion  ta  aetimatod  to  avorao*  1  10  hour*  per  rMporm.  including  the  time  for  rgvmwtng  inetructione,  Marching  exilting  data 
•ourcea,  gathering  end  maintaining  the  data  needed  end  completing  end  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect 
of  thie  collection  of  information,  including  suggestions  for  reducing  the  burden  to  Washington  Headquarters  Services.  Directorate  of  Operations  end  Reports,  1216  Jefferson  Davie 
ighwey.  Suite  1204,  Arlington,  VA  22202-4302,  end  to  the  Office  of  Management  end  Budget,  Paperwork  Reduction  Protect  (0704-01 88}.  Washington  ,  DC  20603. 


COMPUTER  PROGRAMMING  MANUAL  (CPM) 


FJB1S1  il  i!«1?8  Jill  7.1:1  d 


DI-IPSC-81447 


3.  DESCRIPTION /PURPOSE 

3.1  The  Computer  Programming  Manual  (CPM)  provides  information  needed  by  a  programmer  to 
understand  how  to  program  a  given  computer.  This  manual  focuses  on  the  computer  itself,  not  on 
particular  software  that  will  run  on  the  computer. 

3.2  The  CPM  is  intended  for  newly  developed  computers,  special-purpose  computers,  or  other  computers 
for  which  commercial  or  other  programming  manuals  are  not  readily  available. 
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7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  informaton  needed  to  program  the 
computer(s)  on  which  software  was  developed  or  on  which  it  will  run. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80021  A. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


ION  INSTRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7090 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 


Computer  Programming  Manual  (CPM) 
DI-IPSC-81447 


10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 


1. 


Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 


1.1  Identification.  This  paragraph  shall  contain  the  manufacturer's  name,  model  number,  and 
any  other  identifying  information  for  the  computer  system  to  which  this  document  applies. 


1.2  Computer  system  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the 
computer  system  to  which  this  document  applies. 


1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Programming  environment.  This  section  shall  be  divided  into  paragraphs  as  appropriate 
to  provide  the  following  information. 


a.  The  components  and  configuration  of  the  computer  system 


b. 


Operating  characteristics,  capabilities,  and  limitations,  including,  as  applicable: 

1 )  Machine  cycle  time 

2)  Word  length 

3)  Memory  capacity  and  characteristics 

4)  Instruction  set  characteristics 

5)  Interrupt  capabilities 

6)  Modes  of  operation  (e.g.,  batch,  interactive,  privileged,  non-privileged) 

7)  Operational  registers 

8)  Error  indicators 

9)  Input/output  characteristics 

1 0)  Special  features 


c.  Description  of  the  equipment  (e.g.,  tapes,  disks,  other  peripheral  equipment) 
necessary  to  perform  compilations  and  assemblies  on  the  computer  system.  Identify 
(as  applicable)  by  name  and  version  number  the  editor,  linker,  link-editor,  compiler, 
assembler,  cross-compilers,  cross-assemblers,  and  other  utilities  used,  and  reference 
appropriate  manuals  describing  their  use.  Highlight  any  special  flags  or  instructions 
necessary  for  loading,  executing,  or  recording  the  results. 


4.  Programming  information.  This  section  shall  be  divided  into  paragraphs  as  appropriate  to 
provide  the  following  information. 


a. 


Description  of  the  programming  features  of  the  computer's  instruction  set  architec¬ 
ture,  including,  as  applicable: 

1)  Data  representation  (e.g.,  byte,  word,  integer,  floating-point,  double  precision) 

2)  Instruction  formats  and  addressing  modes 

3)  Special  registers  and  words  (e.g.,  stack  pointer,  program  counter) 

4)  Control  instructions  (e.g.,  branch,  jump,  subroutine  and  procedure  call  instruc¬ 
tions,  privileged  instructions,  and  the  modes  they  operate  in) 
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5)  Subroutines  and  procedures  (e.g.,  non-reentrant,  reentrant,  macrocode  routines, 
argument  lists,  parameter  passing  conventions) 

6)  Interrupt  processing 

7)  Timers  and  clocks 

8)  Memory  protection  features  (e.g.,  read-only  memory) 

9)  Additional  features,  such  as  instruction  or  data  cache  architecture 

b.  Description  of  each  instruction,  including,  as  applicable: 

1)  Use 

2)  Syntax 

3)  Condition  codes  set 

4)  Execution  time 

5)  Machine-code  format 

6)  Mnemonic  conventions 

7)  Other  characteristics 

c.  Description  of  input  and  output  control  programming,  including,  as  applicable: 

1)  Initial  loading  and  verification  of  computer  memory 

2)  Serial  and  parallel  data  channels 

3)  Discrete  inputs  and  outputs 

4)  Interface  components 

5)  Device  numbers,  operational  codes,  and  memory  locations  for  peripheral 
equipment 

d.  Additional,  restricted,  or  special  programming  techniques  associated  with  the 
computer  system  (e.g.,  a  concise  description  of  the  microprogram  control  section) 

e.  Examples  that  demonstrate  the  programming  features  described  above,  including 
examples  of  the  proper  use  of  all  categories  of  instructions  on  the  computer  system 

f.  Error  detection  and  diagnostic  features  associated  with  the  computer  system, 
including  condition  codes,  overflow  and  addressing  exception  interrupts,  and  input 
and  output  error  status  indicators 

5.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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3.  DESCRIPTION /PURPOSE 

3.1  The  Database  Design  Description  (DBDD)  describes  the  design  of  a  database,  that  is,  a  collection  of 
related  data  stored  in  one  or  more  computerized  files  in  a  manner  that  can  be  accessed  by  users  or 
computer  programs  via  a  database  management  system  (DBMS).  It  can  also  describe  the  software  units 
used  to  access  or  manipulate  the  data. 

3.2  The  DBDD  is  used  as  the  basis  for  implementing  the  database  and  related  software  units.  It  provides 
the  acquirer  visibility  into  the  design  and  provides  information  needed  for  software  support. 


4.  APPROVAL  DATE  S.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

(VYMMOOI  94-1205  EC 


7.  APPLICATION /INTERRELATIONSHIP 


6a.  DTIC  APPLICABLE  I  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  design  of  one  or  more 
databases. 

7.3  Software  units  that  access  or  manipulate  the  database  may  be  described  here  or  in  Software  Design 
Descriptions  (SDDs)  (DI-IPSC-81435).  Interfaces  may  be  described  here  or  in  interface  Design  Descriptions 
(IDDs)  (DI-IPSC-81436). 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-IPSC-80692  and  DI-MCCR-80305. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7080 


instructs 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collectioOgPf  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Paae  numberinq/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

9-  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "1 0.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Required  Content  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1 . 1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  database  to  which 
this  document  applies,  including,  as  applicable,  identification  number(s),  title(s), 
abbreviation(s),  version  number(s),  and  release  number(s). 

1.2  Database  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  database  to 
which  this  document  applies.  It  shall  describe  the  general  nature  of  the  database;  summarize 
the  history  of  its  development,  use,  and  maintenance;  identify  the  project  sponsor,  acquirer, 
user,  developer,  and  support  agencies;  identify  current  and  planned  operating  sites;  and  list 
other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Database-wide  design  decisions.  This  section  shall  be  divided  into  paragraphs  as  needed 
to  present  database-wide  design  decisions,  that  is,  decisions  about  the  database's  behavioral 
design  (how  it  will  behave,  from  a  user's  point  of  view,  in  meeting  its  requirements,  ignoring 
internal  implementation)  and  other  decisions  affecting  further  design  of  the  database.  If  all 
such  decisions  are  explicit  in  the  system  or  CSCI  requirements,  this  section  shall  so  state. 
Design  decisions  that  respond  to  requirements  designated  critical,  such  as  those  for  safety, 
security,  or  privacy,  shall  be  placed  in  separate  subparagraphs.  If  a  design  decision  depends 
upon  system  states  or  modes,  this  dependency  shall  be  indicated.  If  some  or  all  of  the  design 
decisions  are  described  in  the  documentation  of  a  custom  or  commercial  database 
management  system  (DBMS),  they  may  be  referenced  from  this  section.  Design  conventions 
needed  to  understand  the  design  shall  be  presented  or  referenced.  Examples  of  database-wide 
design  decisions  are  the  following: 

a.  Design  decisions  regarding  queries  or  other  inputs  the  database  will  accept  and 
outputs  (displays,  reports,  messages,  responses,  etc.)  it  will  produce,  including 
interfaces  with  other  systems,  HWCIs,  CSCIs,  and  users  (5.x.d  of  this  DID  identifies 
topics  to  be  considered  in  this  description).  If  part  or  all  of  this  information  is  given 
in  Interface  Design  Descriptions  (IDDs),  they  may  be  referenced. 

b.  Design  decisions  on  database  behavior  in  response  to  each  input  or  query,  including 
actions,  response  times  and  other  performance  characteristics,  selected 
equations/algorithms/rules,  disposition,  and  handling  of  unallowed  inputs 

c.  Design  decisions  on  how  databases/data  files  will  appear  to  the  user  (4.x  of  this  DID 
identifies  topics  to  be  considered  in  this  description) 

d.  Design  decisions  on  the  database  management  system  to  be  used  (including  name, 
version/release)  and  the  type  of  flexibility  to  be  built  into  the  database  for  adapting 
to  changing  requirements 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Required  Content  (continued) 

e.  Design  decisions  on  the  levels  and  types  of  availability,  security,  privacy,  and 
continuity  of  operations  to  be  offered  by  the  database 

f.  Design  decisions  on  database  distribution  (such  as  client/server),  master  database  file 
updates  and  maintenance,  including  maintaining  consistency,  establishing/  re¬ 
establishing  and  maintaining  synchronization,  enforcing  integrity  and  business  rules 

g.  Design  decisions  on  backup  and  restoration  including  data  and  process  distribution 
strategies,  permissible  actions  during  backup  and  restoration,  and  special 
considerations  for  new  or  non-standard  technologies  such  as  video  and  sound 

h.  Design  decisions  on  repacking,  sorting,  indexing,  synchronization,  and  consistency 
including  automated  disk  management  and  space  reclamation  considerations, 
optimizing  strategies  and  considerations,  storage  and  size  considerations,  and 
population  of  the  database  and  capture  of  legacy  data 

4.  Detailed  design  of  the  database.  This  section  shall  be  divided  into  paragraphs  as  needed 
to  describe  the  detailed  design  of  the  database.  The  number  of  levels  of  design  and  the 
names  of  those  levels  shall  be  based  on  the  design  methodology  used.  Examples  of  database 
design  levels  include  conceptual,  internal,  logical,  and  physical.  If  part  or  all  of  the  design 
depends  upon  system  states  or  modes,  this  dependency  shall  be  indicated.  Design 
conventions  needed  to  understand  the  design  shall  be  presented  or  referenced. 

Note:  This  DID  uses  the  term  "data  element  assembly"  to  mean  any  entity,  relation, 
schema,  field,  table,  array,  etc.,  that  has  structure  (number/order/grouping  of  data 
elements)  at  a  given  design  level  (e.g.,  conceptual,  internal,  logical,  physical)  and  the  term 
"data  element"  to  mean  any  relation,  attribute,  field,  cell,  data  element,  etc.  that  does 
not  have  structure  at  that  level. 

4.x  (Name  of  database  design  level).  This  paragraph  shall  identify  a  database  design  level 
and  shall  describe  the  data  elements  and  data  element  assemblies  of  the  database  in  the 
terminology  of  the  selected  design  method.  The  information  shall  include  the  following,  as 
applicable,  presented  in  any  order  suited  to  the  information  to  be  provided: 

a.  Characteristics  of  individual  data  elements  in  the  database  design,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  field  name  in  the  database) 

e)  Abbreviation  or  synonymous  names  ^ 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Required  Content  (continued) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

b.  Characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays,  displays, 
reports,  etc.)  in  the  database  design,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assemblies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

5-  Detailed  design  of  software  units  used  for  database  access  or  manipulation.  This  section 
shall  be  divided  into  the  following  paragraphs  to  describe  each  software  unit  used  for 
database  access  or  manipulation.  If  part  or  all  of  this  information  is  provided  elsewhere,  such 
as  in  a  Software  Design  Description  (SDD),  the  SDD  for  a  customized  DBMS,  or  the  user 
manual  of  a  commercial  DBMS,  that  information  may  be  referenced  rather  than  repeated  here. 
If  part  or  all  of  the  design  depends  upon  system  states  or  modes,  this  dependency  shall  be 
indicated.  If  design  information  falls  into  more  than  one  paragraph,  it  may  be  presented  once 
and  referenced  from  the  other  paragraphs.  Design  conventions  needed  to  understand  the 
design  shall  be  presented  or  referenced. 

5.x  (Proiect-uniaue  identifier  of  a  software  unit,  or  designator  for  a  group  of  software  units). 
This  paragraph  shall  identify  a  software  unit  by  project-unique  identifier  and  shall  describe  the 
unit.  The  description  shall  include  the  following  information,  as  applicable.  Alternatively,  this 
paragraph  may  designate  a  group  of  software  units  and  identify  and  describe  the  software 
units  in  subparagraphs.  Software  units  that  contain  other  software  units  may  reference  the 
descriptions  of  those  units  rather  than  repeating  information. 

a.  Unit  design  decisions,  if  any,  such  as  algorithms  to  be  used,  if  not  previously  selected 

b.  Any  constraints,  limitations,  or  unusual  features  in  the  design  of  the  software  unit 

c.  The  programming  language  to  be  used  and  rationale  for  its  use  if  other  than  the 
specified  CSCI  language 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Required  Content  (continued) 

d.  If  the  software  unit  consists  of  or  contains  procedural  commands  (such  as  menu 
selections  in  a  database  management  system  (DBMS)  for  defining  forms  and  reports, 
on-line  DBMS  queries  for  database  access  and  manipulation,  input  to  a  graphical  user 
interface  (GUI)  builder  for  automated  code  generation,  commands  to  the  operating 
system,  or  shell  scripts),  a  list  of  the  procedural  commands  and  a  reference  to  user 
manuals  or  other  documents  that  explain  them 

e.  If  the  software  unit  contains,  receives,  or  outputs  data,  a  description  of  its  inputs, 
outputs,  and  other  data  elements  and  data  element  assemblies,  as  applicable.  Data 
local  to  the  software  unit  shall  be  described  separately  from  data  input  to  or  output 
from  the  software  unit.  Interface  characteristics  may  be  provided  here  or  by 
referencing  Interface  Design  Description(s).  If  a  given  interfacing  entity  is  not 
covered  by  this  DBDD  (for  example,  an  external  system)  but  its  interface 
characteristics  need  to  be  mentioned  to  describe  software  units  that  are,  these 
characteristics  shall  be  stated  as  assumptions  or  as  "When  [the  entity  not  covered] 
does  this,  [the  software  unit]  will...."  This  paragraph  may  reference  other  documents 
(such  as  data  dictionaries,  standards  for  protocols,  and  standards  for  user  interfaces) 
in  place  of  stating  the  information  here.  The  design  description  shall  include  the 
following,  as  applicable,  presented  in  any  order  suited  to  the  information  to  be 
provided,  and  shall  note  any  differences  in  these  characteristics  from  the  point  of 
view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
frequency,  or  other  characteristics  of  data  elements): 

1 )  Project-unique  identifier  for  the  interface 

2)  Identification  of  the  interfacing  entities  (software  units,  configuration  items, 
users,  etc.)  by  name,  number,  version,  and  documentation  references,  as 
applicable 

3)  Priority  assigned  to  the  interface  by  the  interfacing  entity(ies) 

4)  Type  of  interface  (such  as  real-time  data  transfer,  storage-and-retrieval  of  data, 
etc.)  to  be  implemented 

5)  Characteristics  of  individual  data  elements  that  the  interfacing  entity(ies)  will 
provide,  store,  send,  access,  receive,  etc.  Paragraph  4.x.a  of  this  DID  identifies 
topics  to  be  covered  in  this  description. 

6)  Characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays, 
displays,  reports,  etc.)  that  the  interfacing  entity(ies)  will  provide,  store,  send, 
access,  receive,  etc.  Paragraph  4.x. b  of  this  DID  identifies  topics  to  be  covered 
in  this  description. 

7)  Characteristics  of  communication  methods  that  the  interfacing  entity(ies)  will  use 
for  the  interface,  such  as: 

a)  Project-unique  identifier(s) 

b)  Communication  links/bands/frequencies/media  and  their  characteristics 
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10.  PREPARATION  INSTRUCTIONS--  10.2  Required  Content  (continued) 

c)  Message  formatting 

d)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

e)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  trans¬ 
fers 

f)  Routing,  addressing,  and  naming  conventions 

g)  Transmission  services,  including  priority  and  grade 

h)  Safety/security/privacy  considerations,  such  as  encryption,  user  authenti¬ 
cation,  compartmentalization,  and  auditing 

8)  Characteristics  of  protocols  that  the  interfacing  entity(ies)  will  use  for  the 
interface,  such  as: 

a)  Project-unique  identifier(s) 

b)  Priority/layer  of  the  protocol 

c)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

d)  Legality  checks,  error  control,  and  recovery  procedures 

e)  Synchronization,  including  connection  establishment,  maintenance,  termina¬ 
tion 

f)  Status,  identification,  and  any  other  reporting  features 

9)  Other  characteristics,  such  as  physical  compatibility  of  the  interfacing  entity(ies) 
(dimensions,  tolerances,  loads,  voltages,  plug  compatibility,  etc.) 

f.  If  the  software  unit  contains  logic,  the  logic  to  be  used  by  the  software  unit, 
including,  as  applicable: 

1 )  Conditions  in  effect  within  the  software  unit  when  its  execution  is  initiated 

2)  Conditions  under  which  control  is  passed  to  other  software  units 

3)  Response  and  response  time  to  each  input,  including  data  conversion,  renaming, 
and  data  transfer  operations 

4)  Sequence  of  operations  and  dynamically  controlled  sequencing  during  the 
software  unit's  operation,  including: 

a)  The  method  for  sequence  control 

b)  The  logic  and  input  conditions  of  that  method,  such  as  timing  variations, 
priority  assignments 

c)  Data  transfer  in  and  out  of  memory 

d)  The  sensing  of  discrete  input  signals,  and  timing  relationships  between 
interrupt  operations  within  the  software  unit 

5)  Exception  and  error  handling 

6.  Requirements  traceability.  This  section  shall  contain: 

a.  Traceability  from  each  database  or  other  software  unit  covered  by  this  DBDD  to  the 
system  or  CSCI  requirements  it  addresses. 
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b.  Traceability  from  each  system  or  CSCI  requirement  that  has  been  allocated  to  a 
database  or  other  software  unit  covered  in  this  DBDD  to  the  database  or  other 
software  units  that  address  it. 

7.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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Public  reporting  burd*n  for  coW*clion  of  thM  information  *•  ootimatod  to  avor^a  110  hours  par  rooponoa,  including  ths  Tima  for  ravtawing  instruction*,  Marching  existing  data 
aourcaa.  gar  haring  and  mwnt  wrung  tha  data  noodod  and  com  plating  and  ravtawing  tha  coUaction  of  information.  Sand  com  manta  rag  ar  ding  ttva  bur  dan  aatimata  or  any  othar  aapact 
of  thus  collection  of  information,  including  auggaationa  tor  reducing  thia  bur  dan  to  Washington  Haadquartars  Sorvicaa.  D  tract  or  at  a  of  Operations  and  Reports,  1216  Jaff  arson  Davw 
Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  tha  Office  of  Management  and  Budgst.  Paperwork  Reduction  Protect  (0704-0188),  Washington  ,  OC  20603. 


FIRMWARE  SUPPORT  MANUAL  (FSM) 


DI-IPSC-81448 


3.  DESCRIPTION /PURPOS 

3.1  The  Firmware  Support  Manual  (FSM)  provides  the  information  needed  to  program  and  reprogram  the 
firmware  devices  of  a  system.  It  applies  to  read  only  memories  (ROMs),  Programmable  ROMs  (PROMs), 
Erasable  PROMs  (EPROMs),  and  other  firmware  devices. 

3.2  The  FSM  describes  the  firmware  devices  and  the  equipment,  software,  and  procedures  needed  to  erase 
firmware  devices,  load  software  into  the  firmware  devices,  verify  the  load  process,  and  mark  the  loaded 
firmware  devices. 


4.  APPROVAL  DATE 
,YVMMD01  941205 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


PPUCATION  /INTERRELATIONSHIP 


6b.  DTIC  APPLICABLE  I  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  information  needed  to  program 
and  reprogram  firmware  devices  in  which  software  will  be  installed. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80022A  and  DI-MCCR-80318. 


8.  APPROVAL  LIMITATION 

Limited  Approve!  from  1 2/5/94  through  1 2/5/96 


t  a  n  daw  it 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7091 


mstructic 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  pane  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberina/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 


1. 


Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 


1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system,  software, 
and  firmware  devices  to  which  this  document  applies,  including,  as  applicable,  identification 
number(s),  title(s),  abbreviation(s),  version  number(s),  and  release  number(s)  of  the  system 
and  software  and  manufacturer's  name  and  model  number  for  each  firmware  device. 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1.3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 


2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 


3.  Firmware  programming  instructions.  This  section  shall  be  divided  into  the  following 
paragraphs. 


3.x  (Identifier  of  programmed  firmware  device).  This  paragraph  shall  state  the  project-unique 
identifier  of  a  programmed  firmware  device  to  be  used  in  the  system  and  shall  be  divided  into 
the  following  subparagraphs. 

3.x.  1  Description  of  pre-programmed  device.  This  paragraph  shall: 


a.  Identify  by  manufacturer's  name  and  model  number  the  firmware  device  to  be 
programmed 

b.  Provide  a  complete  physical  description  of  the  firmware  device,  including  the 
following,  as  applicable: 


1)  Memory  size,  type,  speed,  and  configuration  (such  as  64Kx1,  8Kx8) 

2)  Operating  characteristics  (such  as  access  time,  power  requirements,logic  levels) 

3)  Pin  functional  descriptions 

4)  Logical  interfaces  (such  as  addressing  scheme,  chip  selection) 

5)  Internal  and  external  identification  scheme  used 

6)  Timing  diagrams 

c.  Describe  the  operational  and  environmental  limits  to  which  the  firmware  device  may 
be  subjected  and  still  maintain  satisfactory  operation 


3.x. 2  Software  to  be  programmed  into  the  device.  This  paragraph  shall  identify  by  project- 
unique  identifier(s)  the  software  to  be  programmed  into  the  firmware  device. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

3.x. 3  Programming  equipment.  This  paragraph  shall  describe  the  equipment  to  be  used  for 
programming  and  reprogramming  the  firmware  device.  It  shall  include  computer  equipment, 
general  purpose  equipment,  and  special  equipment  to  be  used  for  device  erasure,  loading, 
verification,  and  marking,  as  applicable.  Each  piece  of  equipment  shall  be  identified  by 
manufacturer's  name,  model  number,  and  any  other  information  that  is  necessary  to  uniquely 
identify  that  piece  of  equipment.  A  description  of  each  piece  of  equipment  shall  be  provided, 
including  its  purpose,  usage,  and  major  capabilities. 

3.x. 4  Programming  software.  This  paragraph  shall  describe  the  software  to  be  used  for 
programming  and  reprogramming  the  firmware  device.  It  shall  include  software  to  be  used 
for  device  erasure,  loading,  verification,  and  marking,  as  applicable.  Each  software  item  shall 
be  identified  by  vendor's  name,  software  name,  number,  version/release,  and  any  other 
information  necessary  to  uniquely  identify  the  software  item.  A  description  of  each  software 
item  shall  be  provided,  including  its  purpose,  usage,  and  major  capabilities. 

3.x. 5  Programming  procedures.  This  paragraph  shall  describe  the  procedures  to  be  used 
for  programming  and  reprogramming  the  firmware  device.  It  shall  include  procedures  to  be 
used  for  device  erasure,  loading,  verification,  and  marking,  as  applicable.  All  equipment  and 
software  necessary  for  each  procedure  shall  be  identified,  together  with  any  security  and 
privacy  measures  to  be  applied. 

3.x. 6  Installation  and  repair  procedures.  This  paragraph  shall  contain  the  installation, 
replacement,  and  repair  procedures  for  the  firmware  device.  This  paragraph  shall  also  include 
remove-and-replace  procedures,  device  addressing  scheme  and  implementation,  description 
of  the  host  board  layout,  and  any  procedures  for  ensuring  continuity  of  operations  in  the  event 
of  emergencies.  Safety  precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included 
where  applicable. 

3. x. 7  Vendor  information.  This  section  shall  include  or  reference  any  relevant  information 
supplied  by  the  vendor(s)  of  the  firmware  device,  programming  equipment,  or  programming 
software. 

4.  Notes.  This  section  shall  contain  any  genera!  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 


DATA  ITEM  DESCRIPTION 


Form  Approved 
OMB  NO. 0704-01 88 


Public  reporting  burden  tor  collection  of  thte  information  m  eetimated  to  average  110  hour*  per  reeponee,  including  the  time  tor  reviewing  instruction*.  eeerchir^  exiatir^}  data 
aourcee,  gathering  end  maintaining  the  data  needed  and  completing  and  reviewing  the  collection  of  information.  Send  com  mania  regarding  thro  burden  eetimate  or  any  other  aepect 
of  thra  collection  of  information,  including  auggeetiona  for  reducing  ttea  burden  to  Washington  Haedquartora  Servtcea,  Directorate  of  Operations  and  Reporta,  1216  Jefferson  Davit 
Highway.  Suita  1204,  Arlington,  VA  22202-4302.  and  to  tha  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-01BB).  Washington  ,  DC  20603. 


INTERFACE  DESIGN  DESCRIPTION  ODD) 


3.  DESCRIPTION /PURPOSE 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

6a.  DTIC  APPLICABLE 

EC 

3.1  The  Interface  Design  Description  (IDD)  describes  the  interface  characteristics  of  one  or  more  systems, 
subsystems,  Hardware  Configuration  Items  (HWCIs),  Computer  Software  Configuration  Items  (CSCIs), 
manual  operations,  or  other  system  components.  An  IDD  may  describe  any  number  of  interfaces. 

3.2  The  IDD  can  be  used  to  supplement  the  System/Subsystem  Design  Description  (SSDD) 

(DI-IPSC-81 432),  Software  Design  Description  (SDD)  (DI-IPSC-81 435),  and  Database  Design  Description 
(DBDD)  (DI-IPSC-81 437).  The  IDD  and  its  companion  Interface  Requirements  Specification  (IRS) 
(DI-IPSC-81 434)  serve  to  communicate  and  control  interface  design  decisions. 


4.  APPROVAL  DATE 

(YYMMDOl  g4 1  205 


7.  APPUCATION /INTERRELATIONSHIP 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  interface  design  of  one  or  more 
systems,  subsystems,  HWCIs,  CSCIs,  manual  operations,  or  other  system  components. 

7.3  The  IRS  specifies  interface  requirements;  the  IDD  describes  interface  characteristics  selected  to  meet 
those  requirements.  The  IDD  may  reference  the  IRS  to  avoid  repeating  information.  The  IDD  can  be  used  to 
supplement  the  SSDD,  SDD,  or  DBDD. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to  be 
delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer  format 
rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering  (CASE)  or 
other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-80027A. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


10.  PREPARATION  INSTRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7079 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier  with  signature  blocks.  The  document  shall  include  a  title  page 
containing,  as  applicable:  document  number;  volume  number;  version/revision  indicator; 
security  markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document 
title;  name,  abbreviation,  and  any  other  identifier  for  the  systems,  subsystems,  or  items 
to  which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing  organiza¬ 
tion;  distribution  statement;  and  signature  blocks  for  the  developer  representative 
authorized  to  release  the  document,  the  acquirer  representative  authorized  to  approve 
the  document,  and  the  dates  of  release/approval.  For  data  in  a  database  or  other 
alternative  form,  this  information  shall  be  included  on  external  and  internal  labels  or  by 
equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labeling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "1 0.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system(s),  the 
interfacing  entities,  and  interfaces  to  which  this  document  applies,  including,  as  applicable, 
identification  number(s),  title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 


1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system(s)  and 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 


2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 


3.  Interface  design.  This  section  shall  be  divided  into  the  following  paragraphs  to  describe 
the  interface  characteristics  of  one  or  more  systems,  subsystems,  configuration  items,  manual 
operations,  or  other  system  components.  If  part  or  all  of  the  design  depends  upon  system 
states  or  modes,  this  dependency  shall  be  indicated.  If  design  information  falls  into  more  than 
one  paragraph,  it  may  be  presented  once  and  referenced  from  the  other  paragraphs.  If  part 
or  all  of  this  information  is  documented  elsewhere,  it  may  be  referenced.  Design  conventions 
needed  to  understand  the  design  shall  be  presented  or  referenced. 


3.1  Interface  identification  and  diagrams.  For  each  interface  identified  in  1 .1 ,  this  paragraph 
shall  state  the  project-unique  identifier  assigned  to  the  interface  and  shall  identify  the 
interfacing  entities  (systems,  configuration  items,  users,  etc.)  by  name,  number,  version,  and 
documentation  references,  as  applicable.  The  identification  shall  state  which  entities  have 
fixed  interface  characteristics  (and  therefore  impose  interface  requirements  on  interfacing 
entities)  and  which  are  being  developed  or  modified  (thus  having  interface  requirements 
imposed  on  them).  One  or  more  interface  diagrams  shall  be  provided,  as  appropriate,  to 
depict  the  interfaces. 


3.x  (Proiect-uniaue  identifier  of  interface).  This  paragraph  (beginning  with  3.2)  shall  identify 
an  interface  by  project-unique  identifier;  shall  briefly  identify  the  interfacing  entities,  and  shall 
be  divided  into  subparagraphs  as  needed  to  describe  the  interface  characteristics  of  one  or 
both  of  the  interfacing  entities.  If  a  given  interfacing  entity  is  not  covered  by  this  IDD  (for 
example,  an  external  system)  but  its  interface  characteristics  need  to  be  mentioned  to 
describe  interfacing  entities  that  are,  these  characteristics  shall  be  stated  as  assumptions  or 
as  "When  (the  entity  not  coveredl  does  this,  [the  entity  that  is  covered]  will  ...."  This 
paragraph  may  reference  other  documents  (such  as  data  dictionaries,  standards  for  protocols, 
and  standards  for  user  interfaces)  in  place  of  stating  the  information  here.  The  design 
description  shall  include  the  following,  as  applicable,  presented  in  any  order  suited  to  the 
information  to  be  provided,  and  shall  note  any  differences  in  these  characteristics  from  the 
point  of  view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
frequency,  or  other  characteristics  of  data  elements): 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

a.  Priority  assigned  to  the  interface  by  the  interfacing  entity(ies) 

b.  Type  of  interface  (such  as  real-time  data  transfer,  storage-and-retrieval  of  data,  etc.) 
to  be  implemented 

c.  Characteristics  of  individual  data  elements  that  the  interfacing  entity(ies)  will  provide, 
store,  send,  access,  receive,  etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technica!  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

d.  Characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays,  displays, 
reports,  etc.)  that  the  interfacing  entity(ies)  will  provide,  store,  send,  access,  receive, 
etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assemblies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  {setting/sending  entities)  and  recipients  (using/receiving  entities) 
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e.  Characteristics  of  communication  methods  that  the  interfacing  entity(ies)  will  use  for 
the  interface,  such  as: 

1)  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentalization,  and  auditing 

f .  Characteristics  of  protocols  the  interfacing  entity(ies)  will  use  for  the  interface,  such 
as: 

1)  Project-unique  identifier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  characteristics,  such  as  physical  compatibility  of  the  interfacing  entity(ies) 
(dimensions,  tolerances,  loads,  voltages,  plug  compatibility,  etc.) 

4.  Requirements  traceability.  This  paragraph  shall  contain: 

a.  Traceability  from  each  interfacing  entity  covered  by  this  IDD  to  the  system  or  CSCI 
requirements  addressed  by  the  entity's  interface  design. 

b.  Traceability  from  each  system  or  CSCI  requirement  that  affects  an  interface  covered 
in  this  IDD  to  the  interfacing  entities  that  address  it. 

5.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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INTERFACE  REQUIREMENTS  SPECIFICATION  (IRS) 


3.  DESCRIPTION /PURPOSE 


3.1  The  Interface  Requirements  Specification  (IRS)  specifies  the  requirements  imposed  on  one  or  more 
systems,  subsystems,  Hardware  Configuration  Items  (HWCIs),  Computer  Software  Configuration  Items 
(CSCIs),  manual  operations,  or  other  system  components  to  achieve  one  or  more  interfaces  among  these 
entities.  An  IRS  can  cover  any  number  of  interfaces. 

3.2  The  IRS  can  be  used  to  supplement  the  System/Subsystem  Specification  (SSS)  (DI-IPSC-81 431 )  and 
Software  Requirements  Specification  (SRS)  (DI-IPSC-81 433)  as  the  basis  for  design  and  qualification  testing 
of  systems  and  CSCIs. 


4.  APPROVAL  DATE 
(VYMM0D1  951205 


7.  APPLICATION/INTERRELATIONSHIP 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  interface  requirements  for  one 
or  more  systems,  subsystem,  HWCIs,  CSCIs,  manual  operations,  or  other  system  components. 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

6a.  DTIC  APPLICABLE 

EC 

7-3  The  IRS  can  be  used  to  supplement  the  SSS  and  the  SRS. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-80026A  and  DI-MCCR-80303. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  1 2/5/94  through  1 2/5/96 


CTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7077 


^  ?iri:Tv  iTivirTrF*  i  ? 


instructu 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


1.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier  with  signature  blocks.  The  document  shall  include  a  title  page 
containing,  as  applicable:  document  number;  volume  number;  version/revision  indicator; 
security  markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document 
title;  name,  abbreviation,  and  any  other  identifier  for  the  systems,  subsystems,  or  items 
to  which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing  organiza¬ 
tion;  distribution  statement;  and  signature  blocks  for  the  developer  representative 
authorized  to  release  the  document,  the  acquirer  representative  authorized  to  approve 
the  document,  and  the  dates  of  release/approval.  For  data  in  a  database  or  other 
alternative  form,  this  information  shall  be  included  on  external  and  internal  labels  or  by 
equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberina/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  systems,  the 
interfacing  entities,  and  the  interfaces  to  which  this  document  applies,  including,  as 
applicable,  identification  number(s),  title(s),  abbreviation(s),  version  number(s),  and  release 
number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system(s)  and 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1.3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  specification.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Requirements.  This  section  shall  be  divided  into  the  following  paragraphs  to  specify  the 
requirements  imposed  on  one  or  more  systems,  subsystems,  configuration  items,  manual 
operations,  or  other  system  components  to  achieve  one  or  more  interfaces  among  these 
entities.  Each  requirement  shall  be  assigned  a  project-unique  identifier  to  support  testing  and 
traceability  and  shall  be  stated  in  such  a  way  that  an  objective  test  can  be  defined  for  it.  Each 
requirement  shall  be  annotated  with  associated  qualification  method(s)  (see  section  4)  and 
traceability  to  system  (or  subsystem,  if  applicable)  requirements  (see  section  5.a)  if  not 
provided  in  those  sections.  The  degree  of  detail  to  be  provided  shall  be  guided  by  the 
following  rule:  Include  those  characteristics  of  the  interfacing  entities  that  are  conditions  for 
their  acceptance;  defer  to  design  descriptions  those  characteristics  that  the  acquirer  is  willing 
to  leave  up  to  the  developer.  If  a  given  requirement  fits  into  more  than  one  paragraph,  it  may 
be  stated  once  and  referenced  from  the  other  paragraphs.  If  an  interfacing  entity  included  in 
this  specification  will  operate  in  states  and/or  modes  having  interface  requirements  different 
from  other  states  and  modes,  each  requirement  or  group  of  requirements  for  that  entity  shall 
be  correlated  to  the  states  and  modes.  The  correlation  may  be  indicated  by  a  table  or  other 
method  in  this  paragraph,  in  an  appendix  referenced  from  this  paragraph,  or  by  annotation  of 
the  requirements  in  the  paragraphs  where  they  appear. 

3. 1  Interface  identification  and  diagrams.  For  each  interface  identified  in  1 . 1 ,  this  paragraph 
shall  include  a  project-unique  identifier  and  shall  designate  the  interfacing  entities  (systems, 
configuration  items,  users,  etc.)  by  name,  number,  version,  and  documentation  references, 
as  applicable.  The  identification  shall  state  which  entities  have  fixed  interface  characteristics 
(and  therefore  impose  interface  requirements  on  interfacing  entities)  and  which  are  being 
developed  or  modified  (thus  having  interface  requirements  imposed  on  them).  One  or  more 
interface  diagrams  shall  be  provided  to  depict  the  interfaces. 

3.x  (Project-unique  identifier  of  interface).  This  paragraph  (beginning  with  3.2)  shall  identify 
an  interface  by  project-unique  identifier,  shall  briefly  identify  the  interfacing  entities,  and  shall 
be  divided  into  subparagraphs  as  needed  to  state  the  requirements  imposed  on  one  or  more 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

of  the  interfacing  entities  to  achieve  the  interface.  If  the  interface  characteristics  of  an  entity 
are  not  covered  by  this  IRS  but  need  to  be  mentioned  to  specify  the  requirements  for  entities 
that  are,  those  characteristics  shall  be  stated  as  assumptions  or  as  "When  (the  entity  not 
covered!  does  this,  the  [entity  being  specified]  shall...,"  rather  than  as  requirements  on  the 
entities  not  covered  by  this  IRS.  This  paragraph  may  reference  other  documents  (such  as  data 
dictionaries,  standards  for  communication  protocols,  and  standards  for  user  interfaces)  in 
place  of  stating  the  information  here.  The  requirements  shall  include  the  following,  as 
applicable,  presented  in  any  order  suited  to  the  requirements,  and  shall  note  any  differences 
in  these  characteristics  from  the  point  of  view  of  the  interfacing  entities  (such  as  different 
expectations  about  the  size,  frequency,  or  other  characteristics  of  data  elements): 

a.  Priority  that  the  interfacing  entity(ies)  must  assign  the  interface 

b.  Requirements  on  the  type  of  interface  (such  as  real-time  data  transfer,  storage-and- 
retrieval  of  data,  etc.)  to  be  implemented 

c.  Required  characteristics  of  individual  data  elements  that  the  interfacing  entity(ies) 
must  provide,  store,  send,  access,  receive,  etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 

whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

d.  Required  characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays, 
displays,  reports,  etc.)  that  the  interfacing  entity(ies)  must  provide,  store,  send, 
access,  receive,  etc.,  such  as: 

1)  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assemblies  on  the  medium 
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4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

e.  Required  characteristics  of  communication  methods  that  the  interfacing  entity(ies) 
must  use  for  the  interface,  such  as: 

1 )  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentalization,  and  auditing 

f.  Required  characteristics  of  protocols  the  interfacing  entity(ies)  must  use  for  the 
interface,  such  as: 

1)  Project-unique  identif ier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  required  characteristics,  such  as  physical  compatibility  of  the  interfacing 
entities  (dimensions,  tolerances,  loads,  plug  compatibility,  etc.),  voltages,  etc. 

3. y  Precedence  and  criticality  of  requirements.  This  paragraph  shall  be  numbered  as  the  last 
paragraph  in  Section  3  and  shall  specify,  if  applicable,  the  order  of  precedence,  criticality,  or 
assigned  weights  indicating  the  relative  importance  of  the  requirements  in  this  specification. 
Examples  include  identifying  those  requirements  deemed  critical  to  safety,  to  security,  or  to 
privacy  for  purposes  of  singling  them  out  for  special  treatment.  If  all  requirements  have  equal 
weight,  this  paragraph  shall  so  state. 

4.  Qualification  provisions.  This  section  shall  define  a  set  of  qualification  methods  and  shall 
specify,  for  each  requirement  in  Section  3,  the  qualification  method(s)  to  be  used  to  ensure 
that  the  requirement  has  been  met.  A  table  may  be  used  to  present  this  information,  or  each 
requirement  in  Section  3  may  be  annotated  with  the  method(s)  to  be  used.  Qualification 
methods  may  include: 


Page  of  _g_ 


Interface  Requirements  Specification  (IRS) 

DI-IPSC-81434 

10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

a.  Demonstration:  The  operation  of  interfacing  entities  that  relies  on  observable 
functional  operation  not  requiring  the  use  of  instrumentation,  special  test  equipment, 
or  subsequent  analysis. 

b.  Test:  The  operation  of  interfacing  entities  using  instrumentation  or  special  test 
equipment  to  collect  data  for  later  analysis. 

c.  Analysis:  The  processing  of  accumulated  data  obtained  from  other  qualification 
methods.  Examples  are  reduction,  interpretation,  or  extrapolation  of  test  results. 

d.  Inspection:  The  visual  examination  of  interfacing  entities,  documentation,  etc. 

e.  Special  qualification  methods:  Any  special  qualification  methods  for  the  interfacing 
entities,  such  as  special  tools,  techniques,  procedures,  facilities,  and  acceptance 
limits. 

5.  Requirements  traceability.  For  system-level  interfacing  entities,  this  paragraph  does  not 
apply.  For  each  subsystem-  or  lower-level  interfacing  entity  covered  by  this  IRS,  this 
paragraph  shall  contain: 

a.  Traceability  from  each  requirement  imposed  on  the  entity  in  this  specification  to  the 
system  (or  subsystem,  if  applicable)  requirements  it  addresses.  (Alternatively,  this 
traceability  may  be  provided  by  annotating  each  requirement  in  Section  3.) 

Note:  Each  level  of  system  refinement  may  result  in  requirements  not  directly 
traceable  to  higher-level  requirements.  For  example,  a  system  architectural  design 
that  creates  multiple  CSCIs  may  result  in  requirements  about  how  the  CSCIs  will 
interface,  even  though  these  interfaces  are  not  covered  in  system  requirements. 
Such  requirements  may  be  traced  to  a  general  requirement  such  as  "system 
implementation"  or  to  the  system  design  decisions  that  resulted  in  their  generation. 

b.  Traceability  from  each  system  (or  subsystem,  if  applicable)  requirement  that  has  been 
allocated  to  the  interfacing  entity  and  that  affects  an  interface  covered  in  this 
specification  to  the  requirements  in  this  specification  that  address  it. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  i%in  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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OPERATIONAL  CONCEPT  DESCRIPTION  (0CD) 


3.  DESCRIPTION /PURP0S 


3.1  The  Operational  Concept  Description  (OCD)  describes  a  proposed  system  in  terms  of  the  user  needs  it 
will  fulfill,  its  relationship  to  existing  systems  or  procedures,  and  the  ways  it  will  be  used. 

3.2  The  OCD  is  used  to  obtain  consensus  among  the  acquirer,  developer,  support,  and  user  agencies  on 
the  operational  concept  of  a  proposed  system.  Depending  on  its  use,  an  OCD  may  focus  on  communicating 
the  user's  needs  to  the  developer  or  the  developer's  ideas  to  the  user  and  other  interested  parties.  The 
term  "system"  may  be  interpreted  to  apply  to  a  portion  of  a  system. 


4.  APPROVAL  DATE 

,VYMMDO'  941205 


_ EaSWHafEgfiglf4= 


6.  OFFICE  OF  PRIMARY  RESPONSIBILITY 
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6a.  DTIC  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  operational  concept  for  a 
system. 

7-3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
e  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-IPSC-80689. 


8.  APPROVAL  UMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 
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9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7073 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numbering/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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1  •  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  to  which 
this  document  applies,  including,  as  applicable,  identification  number(s),  title(s),  abbrevia- 
tion(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  to  which 
this  document  applies.  It  shall  describe  the  general  nature  of  the  system;  summarize  the 
history  of  system  development,  operation,  and  maintenance;  identify  the  project  sponsor, 
acquirer,  user,  developer,  and  support  agencies;  identify  current  and  planned  operating  sites; 
and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Current  system  or  situation.  This  section  shall  be  divided  into  the  following  paragraphs 
to  describe  the  system  or  situation  as  it  currently  exists. 

3.1  Background,  objectives,  and  scope.  This  paragraph  shall  describe  the  background, 
mission  or  objectives,  and  scope  of  the  current  system  or  situation. 

3.2  Operational  policies  and  constraints.  This  paragraph  shall  describe  any  operational 
policies  and  constraints  that  apply  to  the  current  system  or  situation. 

3.3  Description  of  current  system  or  situation.  This  paragraph  shall  provide  a  description  of 
the  current  system  or  situation,  identifying  differences  associated  with  different  states  or 
modes  of  operation  (for  example,  regular,  maintenance,  training,  degraded,  emergency, 
alternative-site,  wartime,  peacetime).  The  distinction  between  states  and  modes  is  arbitrary. 
A  system  may  be  described  in  terms  of  states  only,  modes  only,  states  within  modes,  modes 
within  states,  or  any  other  scheme  that  is  useful.  If  the  system  operates  without  states  or 
modes,  this  paragraph  shall  so  state,  without  the  need  to  create  artificial  distinctions.  The 
description  shall  include,  as  applicable: 

a.  The  operational  environment  and  its  characteristics 

b.  Major  system  components  and  the  interconnections  among  these  components 

c.  Interfaces  to  external  systems  or  procedures 

d.  Capabilities/functions  of  the  current  sys^m 

e.  Charts  and  accompanying  descriptions  depicting  inputs,  outputs,  data  flow,  and 
manual  and  automated  processes  sufficient  to  understand  the  current  system  or 
situation  from  the  user's  point  of  view 

f.  Performance  characteristics,  such  as  speed,  throughput,  volume,  frequency 
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g.  Quality  attributes,  such  as  reliability,  maintainability,  availability,  flexibility,  portability, 
usability,  efficiency 

h.  Provisions  for  safety,  security,  privacy,  and  continuity  of  operations  in  emergencies 

3.4  Users  or  involved  personnel.  This  paragraph  shall  describe  the  types  of  users  of  the 
system,  or  personnel  involved  in  the  current  situation,  including,  as  applicable,  organizational 
structures,  training/skills,  responsibilities,  activities,  and  interactions  with  one  another. 

3.5  Support  concept.  This  paragraph  shall  provide  an  overview  of  the  support  concept  for 
the  current  system,  including,  as  applicable  to  this  document,  support  agency(ies);  facilities; 
equipment;  support  software;  repair/replacement  criteria;  maintenance  levels  and  cycles;  and 
storage,  distribution,  and  supply  methods. 

4.  Justification  for  and  nature  of  changes.  This  section  shall  be  divided  into  the  following 
paragraphs. 

4.1  Justification  for  change.  This  paragraph  shall: 

a.  Describe  new  or  modified  aspects  of  user  needs,  threats,  missions,  objectives,  envi¬ 
ronments,  interfaces,  personnel  or  other  factors  that  require  a  new  or  modified 
system 

b.  Summarize  deficiencies  or  limitations  in  the  current  system  or  situation  that  make  it 
unable  to  respond  to  these  factors 

4.2  Description  of  needed  changes.  This  paragraph  shall  summarize  new  or  modified 
capabilities/functions,  processes,  interfaces,  or  other  changes  needed  to  respond  to  the 
factors  identified  in  4.1. 

4.3  Priorities  among  the  changes.  This  paragraph  shall  identify  priorities  among  the  needed 
changes.  It  shall,  for  example,  identify  each  change  as  essential,  desirable,  or  optional,  and 
prioritize  the  desirable  and  optional  changes. 

4.4  Changes  considered  but  not  included.  This  paragraph  shall  identify  changes  considered 
but  not  included  in  4.2,  and  rationale  for  not  including  them. 

4.5  Assumptions  and  constraints.  This  paragraph  shall  identify  any  assumptions  and 
constraints  applicable  to  the  changes  identified  in  this  section. 

5.  Concept  for  a  new  or  modified  system.  This  section  shall  be  divided  into  the  following 
paragraphs  to  describe  a  new  or  modified  system. 

5.1  Background,  objectives,  and  scope.  This  paragraph  shall  describe  the  background, 
mission  or  objectives,  and  scope  of  the  new  or  modified  system. 

5.2  Operational  policies  and  constraints.  This  paragraph  shall  describe  any  operational 
policies  and  constraints  that  apply  to  the  new  or  modified  system. 
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5.3  Description  of  the  new  or  modified  system.  This  paragraph  shall  provide  a  description 
of  the  new  or  modified  system,  identifying  differences  associated  with  different  states  or 
modes  of  operation  (for  example,  regular,  maintenance,  training,  degraded,  emergency, 
alternative-site,  wartime,  peacetime).  The  distinction  between  states  and  modes  is  arbitrary. 
A  system  may  be  described  in  terms  of  states  only,  modes  only,  states  within  modes,  modes 
within  states,  or  any  other  scheme  that  is  useful.  If  the  system  operates  without  states  or 
modes,  this  paragraph  shall  so  state,  without  the  need  to  create  artificial  distinctions.  The 
description  shall  include,  as  applicable: 

a.  The  operational  environment  and  its  characteristics 

b.  Major  system  components  and  the  interconnections  among  these  components 

c.  Interfaces  to  external  systems  or  procedures 

d.  Capabilities/functions  of  the  new  or  modified  system 

e.  Charts  and  accompanying  descriptions  depicting  inputs,  outputs,  data  flow,  and 
manual  and  automated  processes  sufficient  to  understand  the  new  or  modified 
system  or  situation  from  the  user's  point  of  view 

f.  Performance  characteristics,  such  as  speed,  throughput,  volume,  frequency 

g.  Quality  attributes,  such  as  reliability,  maintainability,  availability,  flexibility,  portability, 
usability,  efficiency 

h.  Provisions  for  safety,  security,  privacy,  and  continuity  of  operations  in  emergencies 

5.4  Users/affected  personnel.  This  paragraph  shall  describe  the  types  of  users  of  the  new 
or  modified  system,  including,  as  applicable,  organizational  structures,  training/skills,  responsi¬ 
bilities,  and  interactions  with  one  another. 

5.5  Support  concept.  This  paragraph  shall  provide  an  overview  of  the  support  concept  for 
the  new  or  modified  system,  including,  as  applicable,  support  agency(ies);  facilities; 
equipment;  support  software;  repair/replacement  criteria;  maintenance  levels  and  cycles;  and 
storage,  distribution,  and  supply  methods. 

6.  Operational  scenarios.  This  section  shall  describe  one  or  more  operational  scenarios  that 
illustrate  the  role  of  the  new  or  modified  system,  its  interaction  with  users,  its  interface  to 
other  systems,  and  all  states  or  modes  identified  for  the  system.  The  scenarios  shall  include 
events,  actions,  stimuli,  information,  interactions,  etc.,  as  applicable.  Reference  may  be  made 
to  other  media,  such  as  videos,  to  provide  part  or  all  of  this  information. 

7.  Summary  of  impacts.  This  section  shall  be  divided  into  the  following  paragraphs. 

7.1  Operational  impacts.  This  paragraph  shall  describe  anticipated  operational  impacts  on 
the  user,  acquirer,  developer,  and  support  agency(ies).  These  impacts  may  include  changes 
in  interfaces  with  computer  operating  centers;  change  in  procedures;  use  of  new  data 
sources;  changes  in  quantity,  type,  and  timing  of  data  to  be  input  to  the  system;  changes  in 
data  retention  requirements;  and  new  modes  of  operation  based  on  peacetime,  alert,  wartime, 
or  emergency  conditions. 
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7.2  Organizational  impacts.  This  paragraph  shall  describe  anticipated  organizational  impacts 
on  the  user,  acquirer,  developer,  and  support  agency(ies).  These  impacts  may  include 
modification  of  responsibilities;  addition  or  elimination  of  responsibilities  or  positions;  need  for 
training  or  retraining;  and  changes  in  number,  skill  levels,  position  identifiers,  or  location  of 
personnel  in  various  modes  of  operation. 

7.3  Impacts  during  development.  This  paragraph  shall  describe  anticipated  impacts  on  the 
user,  acquirer,  developer,  and  support  agency(ies)  during  the  development  effort.  These 
impacts  may  include  meetings/discussions  regarding  the  new  system;  development  or 
modification  of  databases;  training;  parallel  operation  of  the  new  and  existing  systems; 
impacts  during  testing  of  the  new  system;  and  other  activities  needed  to  aid  or  monitor 
development. 

8.  Analysis  of  the  proposed  system. 

8.1  Summary  of  advantages.  This  paragraph  shall  provide  a  qualitative  and  quantitative 
summary  of  the  advantages  to  be  obtained  from  the  new  or  modified  system.  This  summary 
shall  include  new  capabilities,  enhanced  capabilities,  and  improved  performance,  asapplicable, 
and  their  relationship  to  deficiencies  identified  in  4.1. 

8.2  Summary  of  disadvantages/limitations.  This  paragraph  shall  provide  a  qualitative  and 
quantitative  summary  of  disadvantages  or  limitations  of  the  new  or  modified  system.  These 
disadvantages  and  limitations  shall  include,  as  applicable,  degraded  or  missing  capabilities, 
degraded  or  less-than-desired  performance,  greater-than-desired  use  of  computer  hardware 
resources,  undesirable  operational  impacts,  conflicts  with  user  assumptions,  and  other 
constraints. 

8.3  Alternatives  and  trade-offs  considered.  This  paragraph  shall  identify  and  describe  major 
alternatives  considered  to  the  system  or  its  characteristics,  the  trade-offs  among  them,  and 
rationale  for  the  decisions  reached. 

9-  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 


Page  6  of  6 


DATA  ITEM  DESCRIPTION 


Form  Approved 
OMB  NO. 0704  01 88 


Public  reporting  burb*n  tor  collection  of  the*  information  m  oatimatod  to  average  1  10  hour*  par  raaponoa.  including  tho  tima  (or  ra  via  wing  mat  ruction*,  *aarcf*ng  *Mt*t«ng  bat* 

*  our  co*.  gat  ho  ring  and  maintaining  tha  data  naadad  and  competing  and  ra  via  wing  tba  collodion  of  information  Sand  com  manta  rag  ar  ding  thia  bur  dan  aatimat*  or  any  othar  aapact 
of  thra  collection  of  information,  Including  auggaationa  for  reducing  thm  bur  dan  to  Washington  Hoadquartara  Sarvicaa.  Directorate  of  O  par  at  ions  and  Report* ,  1216  Jsftarson  Davis 
Highway,  Suit#  1204,  Arlington,  VA  22202*4302,  and  to  the  Office  of  Management  and  Budgat,  Paperwork  Reduction  Protect  (0704-0 IBB),  Washington  ,  DC  20603. 


1.  TITLE 

SOFTWARE  CENTER  OPERATOR  MANUAL  (SCOM) 


3.  DESCRIPTION /PURPOS 

3.1  The  Software  Center  Operator  Manual  (SCOM)  provides  personnel  in  a  computer  center  or  other 
centralized  or  networked  software  installation  information  on  how  to  install  and  operate  a  software  system. 

3.2  The  SCOM  is  developed  for  software  systems  that  will  be  installed  in  a  computer  center  or  other 
centralized  or  networked  software  installation,  with  users  accessing  the  system  via  terminals  or  personal 
computers  or  submitting  and  receiving  inputs  and  outputs  in  batch  or  interactive  mode. 


4.  APPROVAL  DATE 
(YYMMDD,  941  205 


UCATION/IN 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


RELATIONSHIP 


6a.  OTIC  APPLICABLE  6b.  GIDEP  APPUCABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  information  needed  by  persons 
who  will  operate  software  in  a  computer  center  or  other  centralized  or  networked  software  installation,  so 
that  the  software  can  be  used  by  others. 

7.3  This  DID  is  often  used  with  the  Software  Input/Output  Manual  (SIOM)  (DI-IPSC-81445).  This  pair  of 
manuals  is  an  alternative  to  the  Software  User  Manual  (SUM)  (DI-IPSC-81443). 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-IPSC-80695. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7087 


mstructu 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberina/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Software  summary.  This  section  shall  be  divided  into  the  following  paragraphs. 

3.1  Software  application.  This  paragraph  shall  provide  a  brief  description  of  the  intended 
uses  of  the  software.  Capabilities,  operating  improvements,  and  benefits  expected  from  its 
use  shall  be  described. 

3.2  Software  inventory.  This  paragraph  shall  identify  all  software  files,  including  databases 
and  data  files,  that  must  be  installed  for  the  software  to  operate.  The  identification  shall 
include  security  and  privacy  considerations  for  each  file  and  identification  of  the  software 
necessary  to  continue  or  resume  operation  in  case  of  an  emergency. 

3.3  Software  environment.  This  paragraph  shall  identify  the  hardware,  software,  manual 
operations,  and  other  resources  needed  to  install  and  operate  the  software.  Included,  as 
applicable,  shall  be  identification  of: 

a.  Computer  equipment  that  must  be  present,  including  amount  of  memory  needed, 
amount  of  auxiliary  storage  needed,  and  peripheral  equipment  such  as  terminals, 
printers,  and  other  input/output  devices 

b.  Communications  equipment  that  must  be  present 

c.  Other  software  that  must  be  present,  such  as  networking  software,  operating 
systems,  databases,  data  files,  utilities,  permanent  files  that  are  referenced,  created, 
or  updated  by  the  software;  and  databases/data  files  necessary  to  resume  operation 
in  the  event  of  emergencies 

d.  Forms,  procedures,  or  other  manual  operations  that  must  be  present 

e.  Other  facilities,  equipment,  or  resources  that  must  be  present 
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10.  PREPARATION  INSTRUCTIONS--  10.2  Content  Requirements  (continued) 

3.4  Software  organization  and  overview  of  operation.  This  paragraph  shall  provide  a  brief 
description  of  the  organization  and  operation  of  the  software  from  the  operator's  point  of 
view.  The  description  shall  include,  as  applicable: 

a.  Logical  components  of  the  software,  from  the  operator's  point  of  view,  and  an 
overview  of  the  purpose/operation  of  each  component 

b.  Types  of  inputs/access  that  can  be  made  to  the  software  and  the  software's 
response  to  each  type 

c.  The  reports  and  other  outputs  that  are  produced  by  the  software,  including  security 
and  privacy  considerations  for  each 

d.  Typical  run  times  and  factors  that  affect  it 

e.  Organization  of  software  operation  into  runs.  This  description  shall  use  a  chart,  if 
applicable,  showing  how  the  different  operations  are  interrelated.  If  sets  of  runs  are 
grouped  by  time  periods  or  cycles,  each  set  of  integrated  operations  required  on  a 
daily,  weekly,  etc.,  basis  shall  be  presented.  If  runs  may  be  grouped  logically  by 
organizational  level,  the  groups  of  runs  that  can  be  performed  by  each  organizational 
level  such  as  headquarters  processing,  field  activity  processing,  etc.,  shall  be 
presented. 

f.  Any  system  restrictions,  waivers  of  operational  standards,  information  oriented 
toward  specific  support  areas  (for  example,  library,  small  computer  and  teleproces¬ 
sing  support,  interfaces  with  other  systems),  or  other  special  aspects  of  processing 

g.  General  description  of  the  communications  functions  and  processes  of  the  software, 
including,  as  applicable,  a  diagram  of  the  communications  network  used  in  the 
system 

3.5  Contingencies  and  alternate  states  and  modes  of  operation.  This  paragraph  shall  explain 
the  differences  in  software  operation  at  times  of  emergency  and  in  various  states  and  modes 
of  operation,  if  applicable. 

3.6  Security  and  privacy.  This  paragraph  shall  contain  an  overview  of  the  security  and 
privacy  considerations  associated  with  the  software.  A  warning  shall  be  included  regarding 
making  unauthorized  copies  of  software  or  documents,  if  applicable. 

3.7  Assistance  and  problem  reporting.  This  paragraph  shall  identify  points  of  contact  and 
procedures  to  be  followed  to  obtain  assistance  and  report  problems  encountered  in  operating 
the  software. 

4.  Installation  and  setup.  This  paragraph  shall  describe  any  procedures  that  the  operator 
must  perform  to  install  the  software  on  the  equipment,  to  configure  the  software,  to  delete 
or  overwrite  former  files  or  data,  and  to  enter  parameters  for  software  operation.  Safety 
precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included  where  applicable. 
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10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 


5.  Description  of  runs.  This  section  shall  be  divided  into  the  following  paragraphs  to  provide 
a  description  of  the  runs  to  be  performed.  Safety  precautions,  marked  by  WARNING  or 
CAUTION,  shall  be  included  where  applicable. 


5. 1  Run  inventory.  This  paragraph  shall  provide  a  list  of  the  runs  to  be  performed,  identifying 
the  software  and  the  jobs  that  make  up  each  run.  It  shall  include  a  brief  summary  of  the 
purpose  of  each  run  and  shall  relate  the  list  to  the  run  descriptions  included  in  the  remainder 
of  this  section. 


5.2  Phasing.  This  paragraph  shall  describe  acceptable  phasing  of  the  software  into  a  logical 
series  of  operations.  A  run  may  be  phased  to  permit  manual  or  semiautomatic  checking  of 
intermediate  results,  to  provide  the  user  with  intermediate  results  for  other  purposes,  or  to 
permit  a  logical  break  if  higher  priority  jobs  are  submitted.  An  example  of  the  minimum 
division  for  most  systems  would  be  edit,  file  update,  and  report  preparation. 


5.3  Diagnostic  procedures.  This  paragraph  shall  provide  the  setup  and  execution  procedures 
for  any  software  diagnostics.  Included  shall  be  procedures  for  validation  and  trouble  shooting. 
All  parameters  (both  input  and  output),  codes,  and  range  values  for  diagnostic  software  shall 
be  explained. 

5.4  Error  messages.  This  paragraph  shall  list  all  error  messages  output  by  the  software, 
along  with  the  meaning  and  corresponding  correction  procedure  for  each  message. 


5.5  Description  of  each  run, 
graphs. 


This  paragraph  shall  be  divided  into  the  following  subpara- 


5.5.  x  Run  description  for  (run  name  or  identifier).  This  paragraph  shall  identify  a  run  and 
shall  be  divided  into  the  following  subparagraphs  to  describe  the  run. 


5.5.x.  1  Control  inputs.  This  paragraph  shall  provide  a  listing  of  the  run  stream  of  job  control 
statements  needed  to  initiate  the  run. 


5. 5.x. 2  Run  management  information.  This  paragraph  shall  provide  the  information  needed 
to  manage  the  run  including,  as  applicable: 


a.  Peripheral  and  resource  requirements 

b.  Security  and  privacy  considerations 

c.  Method  of  initiation,  such  as  on  request,  after  another  run,  or  at  a  predetermined  time 

d.  Estimated  run  time 

e.  Required  turnaround  time 

f.  Messages  and  responses 

g.  Procedures  for  taking  check  points 

h.  Waivers  from  operational  standards 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

5. 5. x. 3  Input-output  files.  This  paragraph  shall  provide  information  about  the  files  and 
databases  that  serve  as  input  to  or  that  are  created  or  updated  by  the  run.  Included  for  each 
shall  be  information  such  as  name,  security  and  privacy,  recording  medium,  retention 
schedule,  and  disposition. 

5.5. X.4  Output  reports.  This  paragraph  shall  provide  information  about  the  reports  that  are 
produced  during  the  run.  Included  for  each  report  shall  be  the  following  information,  as 
applicable:  report  identifier,  product  control  number,  report  control  symbol,  title,  security  and 
privacy,  media  (e.g.,  hard  copy,  magnetic  tape),  volume  of  report,  number  of  copies,  and 
distribution  of  copies. 

5. 5. x. 5  Reproduced  output  reports.  This  paragraph  shall  provide  information  about  computer¬ 
generated  reports  that  are  subsequently  reproduced  by  other  means.  Included  for  each  report 
shall  be  information  such  as  report  identification,  security  and  privacy,  reproduction  technique, 
paper  size,  binding  method,  number  of  copies,  and  distribution  of  copies. 

5. 5. x. 6  Procedures  for  restart/recoverv  and  continuity  of  operations.  This  paragraph  shall 
provide  procedures  to  be  followed  by  operator  personnel  concerning  restart/recovery  in  the 
event  of  a  system  failure  and  for  continuity  of  operations  in  the  event  of  emergencies. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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SOFTWARE  DESIGN  DESCRIPTION  (SDD) 


1 1  •)  iJMli  RE%  r  EUI  Jl!l  1 :1  d:' 


DI-IPSC-81435 


3.  DESCRIPTION /PURPOSE 

3.1  The  Software  Design  Description  (SDD)  describes  the  design  of  a  Computer  Software  Configuration 
Item  (CSCI).  It  describes  the  CSCI-wide  design  decisions,  the  CSCI  architectural  design,  and  the  detailed 
design  needed  to  implement  the  software.  The  SDD  may  be  supplemented  by  Interface  Design  Descriptions 
HDDs)  (DI-IPSC-81436)  and  Database  Design  Descriptions  (DBDDs)  (DI-IPSC-81437)  as  described  in  Block  7 
below. 

3.2  The  SDD,  with  its  associated  IDDs  and  DBDDs,  is  used  as  the  basis  for  implementing  the  software.  It 
provides  the  acquirer  visibility  into  the  design  and  provides  information  needed  for  software  support. 


4.  APPROVAL  DATE 
(YYMMDD)  94 !  205 

5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 

6a.  DTIC  APPLICABLE 

6b.  GIDEP  APPLICABLE 

I  7.  APPLICATION /INTERRELATIONSHIP 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  design  of  a  CSCI. 

7.3  Design  pertaining  to  interfaces  may  be  presented  in  the  SDD  or  in  IDDs.  Design  pertaining  to 
•databases  may  be  presented  in  the  SDD  or  in  DBDDs. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-80012A,  DI-IPSC-80691,  DI-MCCR-80304,  and  DI-MCCR-80306. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


UCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7078 


instructions. 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Paoe  numberina/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1  •  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  CSCI-wide  design  decisions.  This  section  shall  be  divided  into  paragraphs  as  needed  to 
present  CSCI-wide  design  decisions,  that  is,  decisions  about  the  CSCI's  behavioral  design 
(how  it  will  behave,  from  a  user's  point  of  view,  in  meeting  its  requirements,  ignoring  internal 
implementation)  and  other  decisions  affecting  the  selection  and  design  of  the  software  units 
that  make  up  the  CSCI.  If  all  such  decisions  are  explicit  in  the  CSCI  requirements  or  are 
deferred  to  the  design  of  the  CSCI's  software  units,  this  section  shall  so  state.  Design 
decisions  that  respond  to  requirements  designated  critical,  such  as  those  for  safety,  security, 
or  privacy,  shall  be  placed  in  separate  subparagraphs.  If  a  design  decision  depends  upon 
system  states  or  modes,  this  dependency  shall  be  indicated.  Design  conventions  needed  to 
understand  the  design  shall  be  presented  or  referenced.  Examples  of  CSCI-wide  design 
decisions  are  the  following: 

a.  Design  decisions  regarding  inputs  the  CSCI  will  accept  and  outputs  it  will  produce, 
including  interfaces  with  other  systems,  HWCIs,  CSCIs,  and  users  (4.3.x  of  this  DID 
identifies  topics  to  be  considered  in  this  description).  If  part  or  all  of  this  information 
is  given  in  Interface  Design  Descriptions  (IDDs),  they  may  be  referenced. 

b.  Design  decisions  on  CSCI  behavior  in  response  to  each  input  or  condition,  including 
actions  the  CSCI  will  perform,  response  times  and  other  performance  characteristics, 
description  of  physical  systems  modeled,  selected  equations/algorithms/rules,  and 
handling  of  unallowed  inputs  or  conditions. 

c.  Design  decisions  on  how  databases/data  files  will  appear  to  the  user  (4.3.x  of  this 
DID  identifies  topics  to  be  considered  in  this  description).  If  part  or  all  of  this 
information  is  given  in  Database  Design  Descriptions  (DBDDs),  they  may  be 
referenced. 

d.  Selected  approach  to  meeting  safety,  security,  and  privacy  requirements. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

e.  Other  CSCI-wide  design  decisions  made  in  response  to  requirements,  such  as 
selected  approach  to  providing  required  flexibility,  availability,  and  maintainability. 

4.  CSCI  architectural  design.  This  section  shall  be  divided  into  the  following  paragraphs  to 
describe  the  CSCI  architectural  design.  If  part  or  all  of  the  design  depends  upon  system  states 
or  modes,  this  dependency  shall  be  indicated.  If  design  information  falls  into  more  than  one 
paragraph,  it  may  be  presented  once  and  referenced  from  the  other  paragraphs.  Design 
conventions  needed  to  understand  the  design  shall  be  presented  or  referenced. 

4.1  CSCI  components.  This  paragraph  shall: 

a.  Identify  the  software  units  that  make  up  the  CSCI.  Each  software  unit  shall  be 
assigned  a  project-unique  identifier. 

Note:  A  software  unit  is  an  element  in  the  design  of  a  CSCI;  for  example,  a  major 
subdivision  of  a  CSCI,  a  component  of  that  subdivision,  a  class,  object,  module, 
function,  routine,  or  database.  Software  units  may  occur  at  different  levels  of  a 
hierarchy  and  may  consist  of  other  software  units.  Software  units  in  the  design  may 
or  may  not  have  a  one-to-one  relationship  with  the  code  and  data  entities  (routines, 
procedures,  databases,  data  files,  etc.)  that  implement  them  or  with  the  computer 
files  containing  those  entities.  A  database  may  be  treated  as  a  CSCI  or  as  a  software 
unit.  The  SDD  may  refer  to  software  units  by  any  name(s)  consistent  with  the  design 
methodology  being  used. 

b.  Show  the  static  (such  as  "consists  of")  relationship(s)  of  the  software  units.  Multiple 
relationships  may  be  presented,  depending  on  the  selected  software  design 
methodology  (for  example,  in  an  object-oriented  design,  this  paragraph  may  present 
the  class  and  object  structures  as  well  as  the  module  and  process  architectures  of 
the  CSCI). 

c.  State  the  purpose  of  each  software  unit  and  identify  the  CSCI  requirements  and 
CSCI-wide  design  decisions  allocated  to  it.  (Alternatively,  the  allocation  of 
requirements  may  be  provided  in  6. a.) 

d.  Identify  each  software  unit's  development  status/type  (such  as  new  development, 
existing  design  or  software  to  be  reused  as  is,  existing  design  or  software  to  be 
reengineered,  software  to  be  developed  for  reuse,  software  planned  for  Build  N,  etc.) 
For  existing  design  or  software,  the  description  shall  provide  identifying  information, 
such  as  name,  version,  documentation  references,  library,  etc. 

e.  Describe  the  CSCI's  (and  as  applicable,  each  software  unit's)  planned  utilization  of 
computer  hardware  resources  (such  as  processor  capacity,  memory  capacity, 
input/output  device  capacity,  auxiliary  storage  capacity,  and  communications/network 
equipment  capacity).  The  description  shall  cover  all  computer  hardware  resources 
included  in  resource  utilization  requirements  for  the  CSCI,  in  system-level  resource 
allocations  affecting  the  CSCI,  and  in  resource  utilization  measurement  planning  in 
the  Software  Development  Plan.  If  all  utilization  data  for  a  given  computer  hardware 
resource  are  presented  in  a  single  location,  such  as  in  one  SDD,  this  paragraph  may 
reference  that  source.  Included  for  each  computer  hardware  resource  shall  be: 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 


1 )  The  CSCI  requirements  or  system-level  resource  allocations  being  satisfied 

2)  The  assumptions  and  conditions  on  which  the  utilization  data  are  based  (for 
example,  typical  usage,  worst-case  usage,  assumption  of  certain  events) 


3)  Any  special  considerations  affecting  the  utilization  (such  as  use  of  virtual 
memory,  overlays,  or  multiprocessors  or  the  impacts  of  operating  system 
overhead,  library  software,  or  other  implementation  overhead) 


4)  The  units  of  measure  used  (such  as  percentage  of  processor  capacity,  cycles  per 
second,  bytes  of  memory,  kilobytes  per  second) 

5)  The  level(s)  at  which  the  estimates  or  measures  will  be  made  (such  as  software 
unit,  CSCI,  or  executable  program) 


f.  Identify  the  program  library  in  which  the  software  that  implements  each  software  unit 
is  to  be  placed 


4.2  Concept  of  execution.  This  paragraph  shall  describe  the  concept  of  execution  among  the 
software  units.  It  shall  include  diagrams  and  descriptions  showing  the  dynamic  relationship 
of  the  software  units,  that  is,  how  they  will  interact  during  CSCI  operation,  including,  as 
applicable,  flow  of  execution  control,  data  flow,  dynamically  controlled  sequencing,  state 
transition  diagrams,  timing  diagrams,  priorities  among  units,  handling  of  interrupts, 
timing/sequencing  relationships,  exception  handling,  concurrent  execution,  dynamic 
allocation/deallocation,  dynamic  creation/deletion  of  objects,  processes,  tasks,  and  other 
aspects  of  dynamic  behavior. 


4.3  Interface  design.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  interface  characteristics  of  the  software  units.  It  shall  include  both  interfaces 
among  the  software  units  and  their  interfaces  with  external  entities  such  as  systems, 
configuration  items,  and  users.  If  part  or  all  of  this  information  is  contained  in  Interface 
Design  Descriptions  (IDDs),  in  section  5  of  the  SDD,  or  elsewhere,  these  sources  may  be 
referenced. 


4.3.1  Interface  identification  and  diagrams.  This  paragraph  shall  state  the  project-unique 
identifier  assigned  to  each  interface  and  shall  identify  the  interfacing  entities  (software  units, 
systems,  configuration  items,  users,  etc.)  by  name,  number,  version,  and  documentation 
references,  as  applicable.  The  identification  shall  state  which  entities  have  fixed  interface 
characteristics  (and  therefore  impose  interface  requirements  on  interfacing  entities)  and  which 
are  being  developed  or  modified  (thus  having  interface  requirements  imposed  on  them).  One 
or  more  interface  diagrams  shall  be  provided,  as  appropriate,  to  depict  the  interfaces. 


4.3.x  (Proiect-uniaue  identifier  of  interface).  This  paragraph  (beginning  with  4.3.2)  shall 
identify  an  interface  by  project-unique  identifier,  shall  briefly  identify  the  interfacing  entities, 
and  shall  be  divided  into  subparagraphs  as  needed  to  describe  the  interface  characteristics  of 
one  or  both  of  the  interfacing  entities.  If  a  given  interfacing  entity  is  not  covered  by  this  SDD 
(for  example,  an  external  system)  but  its  interface  characteristics  need  to  be  mentioned  to 
describe  interfacing  entities  that  are,  these  characteristics  shall  be  stated  as  assumptions  or 
as  "When  [the  entity  not  covered)  does  this,  [the  entity  that  is  covered)  will  ...."  This 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

paragraph  may  reference  other  documents  (such  as  data  dictionaries,  standards  for  protocols, 
and  standards  for  user  interfaces)  in  place  of  stating  the  information  here.  The  design 
description  shall  include  the  following,  as  applicable,  presented  in  any  order  suited  to  the 
information  to  be  provided,  and  shall  note  any  differences  in  these  characteristics  from  the 
point  of  view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
frequency,  or  other  characteristics  of  data  elements): 

a.  Priority  assigned  to  the  interface  by  the  interfacing  entity(ies) 

b.  Type  of  interface  (such  as  real-time  data  transfer,  storage-and-retrieval  of  data,  etc.) 
to  be  implemented 

c.  Characteristics  of  individual  data  elements  that  the  interfacing  entity(ies)  will  provide, 
store,  send,  access,  receive,  etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

d.  Characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays,  displays, 
reports,  etc.)  that  the  interfacing  entity(ies)  will  provide,  store,  send,  access,  receive, 
etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assemblies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 
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5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

e.  Characteristics  of  communication  methods  that  the  interfacing  entity(ies)  will  use  for 
the  interface,  such  as: 

1)  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentalization,  and  auditing 

f.  Characteristics  of  protocols  that  the  interfacing  entity(ies)  will  use  for  the  interface, 
such  as: 

1)  Project-unique  identifier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  characteristics,  such  as  physical  compatibility  of  the  interfacing  entity(ies) 
(dimensions,  tolerances,  loads,  voltages,  plug  compatibility,  etc.) 

5.  CSCI  detailed  design.  This  section  shall  be  divided  into  the  following  paragraphs  to 
describe  each  software  unit  of  the  CSCI.  If  part  of  all  of  the  design  depends  upon  system 
states  or  modes,  this  dependency  shall  be  indicated.  If  design  information  falls  into  more  than 
one  paragraph,  it  may  be  presented  once  and  referenced  from  the  other  paragraphs.  Design 
conventions  needed  to  understand  the  design  shall  be  presented  or  referenced.  Interface 
characteristics  of  software  units  may  be  described  here,  in  Section  4,  or  in  Interface  Design 
Descriptions  (IDDs).  Software  units  that  are  databases,  or  that  are  used  to  access  or 
manipulate  databases,  may  be  described  here  or  in  Database  Design  Descriptions  (DBDDs). 
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5.x  (Proiect-uniQue  identifier  of  a  software  unit,  or  designator  of  a  group  of  software  units). 
This  paragraph  shall  identify  a  software  unit  by  project-unique  identifier  and  shall  describe  the 
unit.  The  description  shall  include  the  following  information,  as  applicable.  Alternatively,  this 
paragraph  may  designate  a  group  of  software  units  and  identify  and  describe  the  software 
units  in  subparagraphs.  Software  units  that  contain  other  software  units  may  reference  the 
descriptions  of  those  units  rather  than  repeating  information. 

a.  Unit  design  decisions,  if  any,  such  as  algorithms  to  be  used,  if  not  previously  selected 

b.  Any  constraints,  limitations,  or  unusual  features  in  the  design  of  the  software  unit 

c.  The  programming  language  to  be  used  and  rationale  for  its  use  if  other  than  the 
specified  CSCI  language 

d.  If  the  software  unit  consists  of  or  contains  procedural  commands  (such  as  menu 
selections  in  a  database  management  system  (DBMS)  for  defining  forms  and  reports, 
on-line  DBMS  queries  for  database  access  and  manipulation,  input  to  a  graphical  user 
interface  (GUI)  builder  for  automated  code  generation,  commands  to  the  operating 
system,  or  shell  scripts),  a  list  of  the  procedural  commands  and  reference  to  user 
manuals  or  other  documents  that  explain  them 

e.  If  the  software  unit  contains,  receives,  or  outputs  data,  a  description  of  its  inputs, 
outputs,  and  other  data  elements  and  data  element  assemblies,  as  applicable. 
Paragraph  4.3.x  of  this  DID  provides  a  list  of  topics  to  be  covered,  as  applicable. 
Data  local  to  the  software  unit  shall  be  described  separately  from  data  input  to  or 
output  from  the  software  unit.  If  the  software  unit  is  a  database,  a  corresponding 
Database  Design  Description  (DBDD)  shall  be  referenced;  interface  characteristics 
may  be  provided  here  or  by  referencing  section  4  or  the  corresponding  Interface 
Design  Description(s). 

f.  If  the  software  unit  contains  logic,  the  logic  to  be  used  by  the  software  unit, 
including,  as  applicable: 

1 )  Conditions  in  effect  within  the  software  unit  when  its  execution  is  initiated 

2)  Conditions  under  which  control  is  passed  to  other  software  units 

3)  Response  and  response  time  to  each  input,  including  data  conversion,  renaming, 
and  data  transfer  operations 

4)  Sequence  of  operations  and  dynamically  controlled  sequencing  during  the 
software  unit's  operation,  including: 

a)  The  method  for  sequence  control 

b)  The  logic  and  input  conditions  of  that  method,  such  as  timing  variations, 
priority  assignments 

c)  Data  transfer  in  and  out  of  memory 

d)  The  sensing  of  discrete  input  signals,  and  timing  relationships  between 
interrupt  operations  within  the  software  unit 

5)  Exception  and  error  handling 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

6.  Requirements  traceability.  This  section  shall  contain: 

a.  Traceability  from  each  software  unit  identified  in  this  SDD  to  the  CSCI  requirements 
allocated  to  it.  (Alternatively,  this  traceability  may  be  provided  in  4.1.) 

b.  Traceability  from  each  CSCI  requirement  to  the  software  units  to  which  it  is 
allocated. 


7.  Notes.  This  section  shall  contain  any  genera!  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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SOFTWARE  DEVELOPMENT  PLAN  (SDP) 


DI-IPSC-81427 


3.  DESCRIPTION/PURPOSE 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

6a.  DTIC  APPLICABLE 

EC 

3.1  The  Software  Development  Plan  (SDP)  describes  a  developer's  plans  for  conducting  a  software 
development  effort.  The  term  "software  development"  in  this  DID  is  meant  to  include  new  development, 
modification,  reuse,  reengineering,  maintenance,  and  all  other  activities  resulting  in  software  products. 

3.2  The  SDP  provides  the  acquirer  insight  into,  and  a  tool  for  monitoring,  the  processes  to  be  followed  for 
software  development,  the  methods  to  be  used,  the  approach  to  be  followed  for  each  activity,  and  project 
schedules,  organization,  and  resources. 


4.  APPROVAL  DATE 
(VYMMDO,  94 , 205 


7.  APPLICATION /INTERRELATIONSHIP 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  develop  and  record  plans  for  conducting  software 
development  activities. 

7.3  Portions  of  this  plan  may  be  bound  separately  if  this  approach  enhances  their  usability.  Examples 
include  plans  for  software  configuration  management  and  software  quality  assurance. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-80030A,  DI-MCCR-80297,  DI-MCCR-80298,  DI-MCCR-80299, 
DI-MCCR-80300,  and  DI-MCCR-80319. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  1 2/5/94  through  1 2/5/96 


ONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7070 


instructs 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
_DID  means  a  collection  of  data  regardless  of  its  medium. 

% 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier.  The  document  shall  include  a  title  page  containing,  as  appli¬ 
cable:  document  number;  volume  number;  version/revision  indicator;  security  markings 
or  other  restrictions  on  the  handling  of  the  document;  date;  document  title;  name, 
abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to  which  the 
document  applies;  contract  number;  CDRL  item  number;  organization  for  which  the 
document  has  been  prepared;  name  and  address  of  the  preparing  organization;  and 
distribution  statement.  For  data  in  a  database  or  other  alternative  form,  this  information 
shall  be  included  on  external  and  internal  labels  or  by  equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Pane  numberina/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents,  including 
other  project  plans,  may  be  substituted  for  all  or  part  of  the  document  if  they  contain 
the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

1 .4  Relationship  to  other  plans.  This  paragraph  shall  describe  the  relationship,  if  any,  of  the 
SDP  to  other  project  management  plans. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  plan.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Overview  of  required  work.  This  section  shall  be  divided  into  paragraphs  as  needed  to 
establish  the  context  for  the  planning  described  in  later  sections.  It  shall  include,  as 
applicable,  an  overview  of: 

a.  Requirements  and  constraints  on  the  system  and  software  to  be  developed 

b.  Requirements  and  constraints  on  project  documentation 

c.  Position  of  the  project  in  the  system  life  cycle 

d.  The  selected  program/acquisition  strategy  or  any  requirements  or  constraints  on  it 

e.  Requirements  and  constraints  on  project  schedules  and  resources 

f.  Other  requirements  and  constraints,  such  as  on  project  security,  privacy,  methods, 
standards,  interdependencies  in  hardware  and  software  development,  etc. 

4.  Plans  for  performing  general  software  development  activities.  This  section  shall  be  divided 
into  the  following  paragraphs.  Provisions  corresponding  to  non-required  activities  may  be 
satisfied  by  the  words  "Not  applicable."  If  different  builds  or  different  software  on  the  project 
require  different  planning,  these  differences  shall  be  noted  in  the  paragraphs.  In  addition  to 
the  content  specified  below,  each  paragraph  shall  identify  applicable  risks/uncertainties  and 
plans  for  dealing  with  them. 

4. 1  Software  development  process.  This  paragraph  shall  describe  the  software  development 
process  to  be  used.  The  planning  shall  cover  all  contractual  clauses  concerning  this  topic, 
identifying  planned  builds,  if  applicable,  their  objectives,  and  the  software  development 
activities  to  be  performed  in  each  build. 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

4.2  General  plans  for  software  development.  This  paragraph  shall  be  divided  into  the 
following  subparagraphs. 

4.2.1  Software  development  methods.  This  paragraph  shall  describe  or  reference  the 
software  development  methods  to  be  used.  Included  shall  be  descriptions  of  the  manual  and 
automated  tools  and  procedures  to  be  used  in  support  of  these  methods.  The  methods  shall 
cover  all  contractual  clauses  concerning  this  topic.  Reference  may  be  made  to  other 
paragraphs  in  this  plan  if  the  methods  are  better  described  in  context  with  the  activities  to 
which  they  will  be  applied. 

4.2.2  Standards  for  software  products.  This  paragraph  shall  describe  or  reference  the 
standards  to  be  followed  for  representing  requirements,  design,  code,  test  cases,  test 
procedures,  and  test  results.  The  standards  shall  cover  all  contractual  clauses  concerning  this 
topic.  Reference  may  be  made  to  other  paragraphs  in  this  plan  if  the  standards  are  better 
described  in  context  with  the  activities  to  which  they  will  be  applied.  Standards  for  code  shall 
be  provided  for  each  programming  language  to  be  used.  They  shall  include  at  a  minimum: 

a.  Standards  for  format  (such  as  indentation,  spacing,  capitalization,  and  order  of 
information) 

b.  Standards  for  header  comments  (requiring,  for  example,  name/identifier  of  the  code; 
version  identification;  modification  history;  purpose;  requirements  and  design 
decisions  implemented;  notes  on  the  processing  (such  as  algorithms  used, 
assumptions,  constraints,  limitations,  and  side  effects);  and  notes  on  the  data 
(inputs,  outputs,  variables,  data  structures,  etc.) 

c.  Standards  for  other  comments  (such  as  required  number  and  content  expectations) 

d.  Naming  conventions  for  variables,  parameters,  packages,  procedures,  files,  etc. 

e.  Restrictions,  if  any,  on  the  use  of  programming  language  constructs  or  features 

f.  Restrictions,  if  any,  on  the  complexity  of  code  aggregates 

4.2.3  Reusable  software  products.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs. 

4.2.3. 1  Incorporating  reusable  software  products.  This  paragraph  shall  describe  the 
approach  to  be  followed  for  identifying,  evaluating,  and  incorporating  reusable  software 
products,  including  the  scope  of  the  search  for  such  products  and  the  criteria  to  be  used  for 
their  evaluation.  It  shall  cover  all  contractual  clauses  concerning  this  topic.  Candidate  or 
selected  reusable  software  products  known  at  the  time  this  pljp  is  prepared  or  updated  shall 
be  identified  and  described,  together  with  benefits,  drawbacks,  and  restrictions,  as  applicable, 
associated  with  their  use. 

4. 2. 3. 2  Developing  reusable  software  products.  This  paragraph  shall  describe  the  approach 
to  be  followed  for  identifying,  evaluating,  and  reporting  opportunities  for  developing  reusable 
software  products.  It  shall  cover  all  contractual  clauses  concerning  this  topic. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

4.2.4  Handling  of  critical  requirements.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  handling  requirements  designated 
critical.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses  concerning  the 
identified  topic. 

4.2.4. 1  Safety  assurance 

4. 2. 4.2  Security  assurance 

4. 2. 4.3  Privacy  assurance 

4. 2.4.4  Assurance  of  other  critical  requirements 

4.2.5  Computer  hardware  resource  utilization.  This  paragraph  shall  describe  the  approach 
to  be  followed  for  allocating  computer  hardware  resources  and  monitoring  their  utilization. 
It  shall  cover  all  contractual  clauses  concerning  this  topic. 

4.2.6  Recording  rationale.  This  paragraph  shall  describe  the  approach  to  be  followed  for 
recording  rationale  that  will  be  useful  to  the  support  agency  for  key  decisions  made  on  the 
project.  It  shall  interpret  the  term  "key  decisions"  for  the  project  and  state  where  the 
rationale  are  to  be  recorded.  It  shall  cover  all  contractual  clauses  concerning  this  topic. 

4.2.7  Access  for  acquirer  review.  This  paragraph  shall  describe  the  approach  to  be 
followed  for  providing  the  acquirer  or  its  authorized  representative  access  to  developer  and 
subcontractor  facilities  for  review  of  software  products  and  activities.  It  shall  cover  all 
contractual  clauses  concerning  this  topic. 

5.  Plans  for  performing  detailed  software  development  activities.  This  section  shall  be 
divided  into  the  following  paragraphs.  Provisions  corresponding  to  non-required  activities  may 
be  satisfied  by  the  words  "Not  applicable."  If  different  builds  or  different  software  on  the 
project  require  different  planning,  these  differences  shall  be  noted  in  the  paragraphs.  The 
discussion  of  each  activity  shall  include  the  approach  (methods/procedures/tools)  to  be  applied 
to:  1)  the  analysis  or  other  technical  tasks  involved,  2)  the  recording  of  results,  and  3)  the 
preparation  of  associated  deliverables,  if  applicable.  The  discussion  shall  also  identify 
applicable  risks/uncertainties  and  plans  for  dealing  with  them.  Reference  may  be  made  to 

4.2.1  if  applicable  methods  are  described  there. 

5.1  Project  planning  and  oversight.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  project  planning  and  oversight. 
The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified 
topic. 


5.1.1  Software  development  planning  (covering  updates  to  this  plan) 

5.1.2  CSCI  test  planning 

5.1.3  System  test  planning 

5.1.4  Software  installation  planning 

5.1.5  Software  transition  planning 

5.1.6  Following  and  updating  plans,  including  the  intervals  for  management  review 
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10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 

5.2  Establishing  a  software  development  environment.  This  paragraph  shall  be  divided  into 
the  following  subparagraphs  to  describe  the  approach  to  be  followed  for  establishing, 
controlling,  and  maintaining  a  software  development  environment.  The  planning  in  each 
subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.2.1  Software  engineering  environment 

5.2.2  Software  test  environment 

5.2.3  Software  development  library 

5.2.4  Software  development  files 

5.2.5  Non-deliverable  software 

5.3  System  requirements  analysis.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  participating  in  system 
requirements  analysis.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses 
regarding  the  identified  topic. 

5.3.1  Analysis  of  user  input 

5.3.2  Operational  concept 

5.3.3  System  requirements 

5.4  System  design.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  approach  to  be  followed  for  participating  in  system  design.  The  planning  in  each 
subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.4.1  System-wide  design  decisions 

5.4.2  System  architectural  design 

5.5  Software  requirements  analysis.  This  paragraph  shall  describe  the  approach  to  be 
followed  for  software  requirements  analysis.  The  approach  shall  cover  all  contractual  clauses 
concerning  this  topic. 

5.6  Software  design.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  approach  to  be  followed  for  software  design.  The  planning  in  each  subparagraph 
shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.6.1  CSCI-wide  design  decisions 

5.6.2  CSCI  architectural  design 

5.6.3  CSCI  detailed  design 

5.7  Software  implementation  and  unit  testing.  This  paragraph  shall  be  divided  into  the 
following  subparagraphs  to  describe  the  approach  to  be  followed  for  software  implementation 
and  unit  testing.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses 
regarding  the  identified  topic. 

5.7.1  Software  implementation 

5.7.2  Preparing  for  unit  testing 

5.7.3  Performing  unit  testing 

5.7.4  Revision  and  retesting 

5.7.5  Analyzing  and  recording  unit  test  results 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

5.8  Unit  integration  and  testing.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  unit  integration  and  testing.  The 
planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.8.1  Preparing  for  unit  integration  and  testing 

5.8.2  Performing  unit  integration  and  testing 

5.8.3  Revision  and  retesting 

5.8.4  Analyzing  and  recording  unit  integration  and  test  results 

5.9  CSCI  qualification  testing.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  CSCI  qualification  testing.  The 
planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.9.1  Independence  in  CSCI  qualification  testing 

5.9.2  Testing  on  the  target  computer  system 

5.9.3  Preparing  for  CSCI  qualification  testing 

5.9.4  Dry  run  of  CSCI  qualification  testing 

5.9.5  Performing  CSCI  qualification  testing 

5.9.6  Revision  and  retesting 

5.9.7  Analyzing  and  recording  CSCI  qualification  test  results 

5.10  CSCI/HWCI  integration  and  testing.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  participating  in  CSCI/HWCI 
integration  and  testing.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses 
regarding  the  identified  topic. 

5.10.1  Preparing  for  CSCI/HWCI  integration  and  testing 

5.10.2  Performing  CSCI/HWCI  integration  and  testing 

5.10.3  Revision  and  retesting 

5.10.4  Analyzing  and  recording  CSCI/HWCI  integration  and  test  results 

5.11  System  qualification  testing.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  participating  in  system  qualification 
testing.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the 
identified  topic. 

5.11.1  Independence  in  system  qualification  testing 

5.11.2  Testing  on  the  target  computer  system 

5.1 1.3  Preparing  for  system  qualification  testing 

5.1 1 .4  Dry  run  of  system  qualification  testing 

5.11.5  Performing  system  qualification  testing 

5.11.6  Revision  and  retestirtg  ^ 

5.1 1 .7  Analyzing  and  recording  system  qualification  test  results 

5.12  Preparing  for  software  use.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  preparing  for  software  use.  The 
planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 
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5.12.1  Preparing  the  executable  software 

5.12.2  Preparing  version  descriptions  for  user  sites 

5.12.3  Preparing  user  manuals 

5.12.4  Installation  at  user  sites 

5.13  Preparing  for  software  transition.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  preparing  for  software  transition. 
The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified 
topic. 

5.13.1  Preparing  the  executable  software 

5.13.2  Preparing  source  files 

5.13.3  Preparing  version  descriptions  for  the  support  site 

5.13.4  Preparing  the  "as  built"  CSCI  design  and  other  software  support  information 

5.13.5  Updating  the  system  design  description 

5.13.6  Preparing  support  manuals 

5.13.7  Transition  to  the  designated  support  site 

5.14  Software  configuration  management.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs  to  describe  the  approach  to  be  followed  for  software  configuration 
management.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding 
the  identified  topic. 

5.14.1  Configuration  identification 

5.14.2  Configuration  control 

5.14.3  Configuration  status  accounting 

5.14.4  Configuration  audits 

5.14.5  Packaging,  storage,  handling,  and  delivery 

5.15  Software  product  evaluation.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  software  product  evaluation.  The 
planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.15.1  In-process  and  final  software  product  evaluations 

5.15.2  Software  product  evaluation  records,  including  items  to  be  recorded 

5.15.3  Independence  in  software  product  evaluation 

5.16  Software  Quality  assurance.  This  paragraph  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  approach  to  be  followed  for  software  quality  assurance.  The 
planning  in  each  subparagraph  shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.16.1  Software  quality  assurance  evaluations 

5.16.2  Software  quality  assurance  records,  including  items  to  be  recorded 

5.16.3  Independence  in  software  quality  assurance 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

5.17  Corrective  action.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  approach  to  be  followed  for  corrective  action.  The  planning  in  each  subparagraph 
shall  cover  all  contractual  clauses  regarding  the  identified  topic. 

5.17.1  Problem/change  reports,  including  items  to  be  recorded  (candidate  items 
include  project  name,  originator,  problem  number,  problem  name,  software 
element  or  document  affected,  origination  date,  category  and  priority, 
description,  analyst  assigned  to  the  problem,  date  assigned,  date  completed, 
analysis  time,  recommended  solution,  impacts,  problem  status,  approval  of 
solution,  follow-up  actions,  corrector,  correction  date,  version  where 
corrected,  correction  time,  description  of  solution  implemented) 

5.17.2  Corrective  action  system 

5.18  Joint  technical  and  management  reviews.  This  paragraph  shall  be  divided  into  the 
following  subparagraphs  to  describe  the  approach  to  be  followed  for  joint  technical  and 
management  reviews.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses 
regarding  the  identified  topic. 

5.18.1  Joint  technical  reviews,  including  a  proposed  set  of  reviews 

5.18.2  Joint  management  reviews,  including  a  proposed  set  of  reviews 

5.19  Other  software  development  activities.  This  paragraph  shall  be  divided  into  the 
following  subparagraphs  to  describe  the  approach  to  be  followed  for  other  software 
development  activities.  The  planning  in  each  subparagraph  shall  cover  all  contractual  clauses 
regarding  the  identified  topic. 

5.19.1  Risk  management,  including  known  risks  and  corresponding  strategies 

5.19.2  Software  management  indicators,  including  indicators  to  be  used 

5.19.3  Security  and  privacy 

5.19.4  Subcontractor  management 

5.19.5  Interface  with  software  independent  verification  and  validation  (IV&V)  agents 

5.19.6  Coordination  with  associate  developers 

5.19.7  Improvement  of  project  processes 

5.19.8  Other  activities  not  covered  elsewhere  in  the  plan 

6.  Schedules  and  activity  network.  This  section  shall  present: 

a.  Schedule(s)  identifying  the  activities  in  each  build  and  showing  initiation  of  each 
activity,  availability  of  draft  and  final  deliverables  and  other  milestones,  and 
completion  of  each  activity 

b.  An  activity  network,  depicting  sequential  relationships  and  dependencies  among 
activities  and  identifying  those  activities  that  impose  the  greatest  time  restrictions  on 
the  project 
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7.  Project  organization  and  resources.  This  section  shall  be  divided  into  the  following 
paragraphs  to  describe  the  project  organization  and  resources  to  be  applied  in  each  build. 

7.1  Project  organization.  This  paragraph  shall  describe  the  organizational  structure  to  be 
used  on  the  project,  including  the  organizations  involved,  their  relationships  to  one  another, 
and  the  authority  and  responsibility  of  each  organization  for  carrying  out  required  activities. 

7.2  Project  resources.  This  paragraph  shall  describe  the  resources  to  be  applied  to  the 
project.  It  shall  include,  as  applicable: 

a.  Personnel  resources,  including: 

1 )  The  estimated  staff-loading  for  the  project  (number  of  personnel  over  time) 

2)  The  breakdown  of  the  staff-loading  numbers  by  responsibility  (for  example, 
management,  software  engineering,  software  testing,  software  configuration 
management,  software  product  evaluation,  software  quality  assurance) 

3)  A  breakdown  of  the  skill  levels,  geographic  locations,  and  security  clearances  of 
personnel  performing  each  responsibility 

b.  Overview  of  developer  facilities  to  be  used,  including  geographic  locations  in  which 
the  work  will  be  performed,  facilities  to  be  used,  and  secure  areas  and  other  features 
of  the  facilities  as  applicable  to  the  contracted  effort. 

c.  Acquirer-furnished  equipment,  software,  services,  documentation,  data,  and  facilities 
required  for  the  contracted  effort.  A  schedule  detailing  when  these  items  will  be 
needed  shall  also  be  included. 

d.  Other  required  resources,  including  a  plan  for  obtaining  the  resources,  dates  needed, 
and  availability  of  each  resource  item. 

8.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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SOFTWARE  INPUT/OUTPUT  MANUAL  (SIOM) 

DI-IPSC-81445 

1  3.  DESCRIPTION /PURPOSE 

3.1  The  Software  Input/Output  Manual  (SIOM)  tells  a  user  how  to  access,  submit  inputs  to,  and  interpret 
output  from,  a  batch  or  interactive  software  system  that  is  run  by  personnel  in  a  computer  center  or  other 
centralized  or  networked  software  installation. 

3.2  The  SIOM  is  developed  for  software  systems  that  will  be  installed  in  a  computer  center  or  other 
centralized  or  networked  software  installation,  with  users  accessing  the  system  via  terminals  or  personal 
computers  or  submitting  and  receiving  inputs  and  outputs  in  batch  mode. 


4.  APPROVAL  DATE 

onrMMOD'  941205 


OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


6a.  DTIC  APPLICABLE  6b.  QIDEP  APPLICABLE 
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7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  information  needed  by  persons 
who  will  submit  inputs  to,  and  recieve  outputs  from,  software,  relying  on  others  to  operate  the  software  in 
a  computer  center  or  other  centralized  or  networked  software  installation. 

7.3  This  DID  is  often  used  with  the  Software  Center  Operator  Manual  (SCOM)  (DI-IPSC-81444).  This  pair 
of  manuals  is  an  alternative  to  the  Software  User  Manual  (SUM)  (DI-IPSC-81443). 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-IPSC-80693. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


CTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7088 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document’’  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium, 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


1 1 .  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS--  10.1  General  Instructions  (continued) 

c.  Title  oaoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Software  summary.  This  section  shall  be  divided  into  the  following  paragraphs. 

3.1  Software  application.  This  paragraph  shall  provide  a  brief  description  of  the  intended 
uses  of  the  software.  Capabilities,  operating  improvements,  and  benefits  expected  from  its 
use  shall  be  described. 

3.2  Software  inventory.  This  paragraph  shall  identify  the  software  files,  if  any,  including 
databases  and  data  files,  that  the  user  is  responsible  for  requesting  in  order  to  access  the 
software  described  in  this  manual.  The  identification  shall  include  security  and  privacy 
considerations  for  each  file  and  identification  of  the  software  necessary  to  continue  or  resume 
operation  in  case  of  an  emergency. 

3.3  Software  environment.  This  paragraph  shall  identify  the  hardware,  software,  manual 
operations,  and  other  resources  needed  to  access  and  use  the  software.  This  paragraph  shall 
be  based  on  the  assumption  that  the  software  is  installed  in  a  computer  center  or  other 
centralized  or  networked  environment  and  shall  focus  on  the  resources  that  a  user  must  have 
to  access  and  use  the  software  in  that  environment.  Included,  as  applicable,  shall  be 
identification  of: 

a.  Computer  equipment  that  must  be  present,  such  as  terminals,  printers,  or  other 
input/output  devices 

b.  Communications  equipment  that  must  be  present 

c.  Other  software  that  must  be  present,  such  as  networking  software 

d.  Forms,  procedures,  or  other  manual  operations  that  must  be  present 

e.  Other  facilities,  equipment,  or  resources  that  must  be  present 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

3.4  Software  organization  and  overview  of  operation.  This  paragraph  shall  provide  a  brief 
description  of  the  organization  and  operation  of  the  software  from  the  user's  point  of  view. 
The  description  shall  include,  as  applicable: 

a.  Logical  components  of  the  software,  from  the  user's  point  of  view,  including 
databases  and  data  files  the  user  can  access.  Database  Management  Systems 
(DBMSs),  and  communications  paths,  and  an  overview  of  the  purpose/operation  of 
each  component 

b.  Performance  characteristics  that  can  be  expected  by  the  user,  such  as: 

1)  Types,  volumes,  rate  of  inputs  accepted 

2)  Types,  volume,  accuracy,  rate  of  outputs  that  the  software  can  produce 

3)  Typical  response  time  and  factors  that  affect  it 

4)  Typical  processing  time  and  factors  that  affect  it 

5)  Limitations,  e.g,  restrictions  on  what  data  may  be  queried  and  from  what  location 

6)  Error  rate  that  can  be  expected 

7)  Reliability  that  can  be  expected 

c.  Relationships  of  the  functions  performed  by  the  software  with  interfacing  systems 
and  with  the  organizations  or  stations  that  are  sources  of  input  or  recipients  of  output 

d.  Supervisory  controls  that  can  be  implemented  (such  as  passwords)  to  manage  the 
software 

3.5  Contingencies  and  alternate  states  and  modes  of  operation.  This  paragraph  shall  explain 
the  differences  in  what  the  user  will  be  able  to  do  with  the  software  at  times  of  emergency 
and  in  various  states  and  modes  of  operation,  if  applicable. 

3.6  Security  and  privacy.  This  paragraph  shall  contain  an  overview  of  the  security  and 
privacy  considerations  associated  with  the  software.  A  warning  shall  be  included  regarding 
making  unauthorized  copies  of  software  or  documents,  if  applicable. 

3.7  Assistance  and  problem  reporting.  This  paragraph  shall  identify  points  of  contact  and 
procedures  to  be  followed  to  obtain  assistance  and  report  problems  encountered  in  using  the 
software. 

4.  Using  the  software.  This  section  shall  be  divided  into  the  following  paragraphs  to 
describe  how  to  prepare  inputs  to,  and  interpret  output  from,  the  software.  If  the  software 
has  a  query  capability,  this  paragraph  shall  reference  section  5  for  a  description  of  this 
capability.  If  the  software  can  be  accessed  via  terminal,  this  paragraph  shall  reference 
Sections  6  through  n  to  describe  terminal  processing  procedures.  Safety  precautions,  marked 
by  WARNING  or  CAUTION,  shall  be  included  where  applicable. 

4. 1  Initiation  procedures.  This  paragraph  shall  contain  the  procedures  that  must  be  followed 
to  initiate  use  of  the  software.  Included  may  be  information  such  as  sample  job  request  forms 
or  sample  control  statements. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

4.2  Description  of  inputs.  This  paragraph  shall  be  divided  into  the  following  subparagraphs. 

4.2.1  Input  conditions.  This  paragraph  shall  describe  the  conditions  to  be  observed  in 
preparing  each  type  or  class  of  input  to  the  software.  The  conditions  shall  include  the 
following,  as  applicable: 

a.  Reason  for  input,  such  as  normal  status  report,  need  to  update  data 

b.  Frequency  of  input,  such  as  monthly,  on  demand 

c.  Origin  of  input,  such  as  the  organization  or  station  authorized  to  generate  the  input 

d.  Medium  of  input,  such  as  magnetic  tape 

e.  Related  inputs  that  are  required  to  be  entered  at  the  same  time  as  this  input 

f.  Other  applicable  information,  such  as  priority;  security  and  privacy  considerations 

4.2.2  Input  formats.  This  paragraph ’shall  illustrate  the  layout  formats  to  be  used  in  the 
preparation  of  inputs  to  the  software  and  shall  explain  the  information  that  may  be  entered 
in  the  various  sections  and  lines  of  each  format. 

4.2.3  Composition  rules.  This  paragraph  shall  describe  any  rules  and  conventions  that  must 
be  observed  to  prepare  inputs.  The  rules  of  syntax,  usage  of  punctuation,  etc.,  shall  be 
explained.  The  rules  shall  include  the  following,  as  applicable: 

a.  Input  transaction  length,  such  as  100  characters  maximum 

b.  Format  conventions,  such  as  all  input  items  must  be  left-justified 

c.  Labeling,  such  as  usage  of  identifiers  to  denote  major  data  sets  to  the  software 

d.  Sequencing,  such  as  order  and  placement  of  items  in  the  input 

e.  Punctuation,  such  as  spacing  and  use  of  symbols  (virgule,  asterisk,  character 
combinations,  etc.)  to  denote  start  and  end  of  input,  of  data  groups,  and  of  fields 

f.  Restrictions,  such  as  rules  forbidding  use  of  particular  characters  or  parameter  sets 

4.2.4  Input  vocabulary.  This  paragraph  shall  explain  the  legal  character  combinations  or 
codes  that  must  be  used  to  prepare  inputs.  An  appendix  may  be  provided  containing  an 
ordered  listing  of  these  codes. 

4.2.5  Sample  inputs.  This  paragraph  shall  provide  examples  that  illustrate  and  explain  each 
type  or  class  of  input  acceptable  by  the  software.  Included  shall  be  information  on  the 
following  types  of  inputs,  as  applicable: 

a.  Headers  denoting  the  start  of  input 

b.  Text  or  body  of  the  input 

c.  Trailers  denoting  the  end  of  input 

d.  Portions  of  the  input  that  may  be  omitted 

e.  Portions  of  the  input  that  may  be  repeated 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

4.3  Description  of  outputs.  This  paragraph  shall  be  divided  into  the  following  subparagraphs. 

4.3.1  General  description.  This  paragraph  shall  provide  the  following  information,  as 
applicable,  for  each  type  or  class  of  output: 

a.  Reasons  why  the  output  is  generated 

b.  Frequency  of  the  output,  such  as  monthly,  on  demand 

c.  Any  modifications  or  variations  of  the  basic  output  that  are  available 

d.  Media,  such  as  printout,  display  screen,  tape 

e.  Location  where  the  output  will  appear,  such  as  in  the  computer  area  or  remotely 

f.  Any  additional  characteristics,  such  as  priority,  security  and  privacy  considerations, 
associated  outputs  that  complement  the  information  in  this  output 

4.3.2  Output  formats.  This  paragraph  shall  illustrate  and  explain  the  layout  of  each  type 
or  class  of  output  from  the  software.  The  following  aspects  shall  be  explained,  as  applicable: 

a.  Security  and  privacy  markings 

b.  Data  that  may  appear  in  headers 

c.  Information  that  may  appear  in  the  body  or  text  of  the  output,  including  column 
headings  and  subsets  or  sections  in  the  output  format 

d.  Data  that  may  appear  in  trailers 

e.  Additional  characteristics,  such  as  the  meaning  of  special  symbols 

4.3.3  Sample  outputs.  This  paragraph  shall  provide  illustrations  of  each  type  or  class  of 
output  from  the  software.  A  description  of  each  sample  shall  be  provided,  including,  as 
applicable: 

a.  Meaning  and  use  of  each  column,  entry,  etc. 

b.  Source,  such  as  extracted  from  database,  calculated 

c.  Characteristics,  such  as  when  omitted,  range  of  values,  unit  of  measure 

4.3.4  Output  vocabulary.  This  paragraph  shall  describe  any  codes  or  abbreviations  that 
appear  in  the  output  that  differ  from  those  used  in  the  input  described  in  paragraph  4.2.4. 

4.4  Use  of  outputs.  This  paragraph  shall  explain  the  use  of  the  output  by  the  operational 
area  or  activity  that  receives  it. 

4.5  Recovery  and  error  correction  procedures.  This  paragraph  shall  list  the  error  codes 
generated  by  the  software,  give  their  meanings,  and  describe  the  corrective  actions  to  be 
taken  by  the  user.  Also  included  shall  be  the  procedures  to  be  followed  by  the  user  with 
respect  to  restart,  recovery,  and  continuity  of  operations  in  the  event  of  emergencies. 

4.6  Communications  diagnostics.  This  paragraph  shall  describe  the  diagnostic  procedures 
available  to  the  user  for  validating  communications  and  for  identifying  and  classifying 
problems. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

5.  Query  procedures.  This  section  shall  be  prepared  for  software  with  a  query  capability. 
It  shall  be  divided  into  the  following  paragraphs. 

5.1  Database/data  file  format.  This  paragraph  shall  provide  a  user's  view  of  the  format  and 
content  of  each  database  and  data  file  that  can  be  queried.  Figure  1  provides  an  example. 
Information  such  as  the  following  shall  be  provided  for  each  data  element,  as  applicable: 

a.  Data  element  name 

b.  Synonymous  names 

c.  Definition 

d.  Format 

e.  Range  and  enumeration  of  values 

f.  Unit  of  measurement 

g.  Data  item  names,  abbreviations,  and  codes 

5.2  Query  capabilities.  This  paragraph  shall  identify  and  describe  the  preprogrammed  and 
ad  hoc  query  capabilities  provided  by  the  software.  An  example  of  preprogrammed  queries 
is  shown  in  Figure  2. 

5.3  Query  preparation.  This  paragraph  shall  provide  instructions  for  preparing  queries. 
Figure  3  shows  an  example  of  the  format  for  a  preprogrammed  query.  Figure  4  shows  an 
example  of  a  query  statement. 

5.4  Control  instructions.  This  paragraph  shall  provide  instructions  for  the  sequencing  of  runs 
and  other  actions  necessary  to  extract  responses  to  query  requests.  These  instructions  shall 
include  control  statements  that  may  be  required  by  the  computer  system  or  software. 

6.  User  terminal  processing  procedures.  This  section  shall  be  divided  into  the  following 
paragraphs  to  provide  the  user  with  information  on  the  use  of  terminals  to  accomplish 
processing.  If  the  procedures  are  complicated  or  extensive,  Sections  7  through  n  may  be 
added  in  the  same  paragraph  structure  as  this  section  and  with  titles  meaningful  to  the 
sections  selected.  The  organization  of  the  document  will  depend  on  the  characteristics  of  the 
software  being  documented.  For  example,  sections  might  be  based  on  the  organizations  in 
which  users  work,  their  assigned  positions,  work  sites,  or  the  tasks  they  must  perform.  For 
other  software,  it  may  be  more  appropriate  to  have  Section  6  be  a  guide  to  menus.  Section 
7  be  a  guide  to  the  command  language,  and  Section  8  be  a  guide  to  functions.  Detailed 
procedures  are  intended  to  be  presented  in  paragraphs  6.2  through  6.5.  Depending  on  the 
design  of  the  software,  the  subparagraphs  might  be  organized  on  a  function-by-function, 
menu-by-menu,  transaction-by-transaction,  or  other  basis.  Safety  precautions,  marked  by 
WARNING  or  CAUTION,  shall  be  included  where  applicable. 

6. 1  Available  capabilities.  This  paragraph  shall  describe  in  general  terms  the  capabilities  for 
retrieval,  display,  and  update  of  data  through  terminal  operations. 

6.2  Access  procedures.  This  paragraph  shall  present  the  sequence  of  steps  and  any 
applicable  rules  pertaining  to  accessing  the  software  to  initiate  software  operations. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

6.3  Display,  updates,  and  retrieval  procedures.  This  paragraph  shall  be  divided  into 
subparagraphs  to  provide  the  step-by-step  procedures  necessary  to  produce  the  displays, 
updates,  and  retrievals  that  are  available  through  the  use  of  a  terminal.  Each  procedure  shall 
include  the  name  of  the  operation,  input  formats,  and  sample  responses,  as  applicable. 

6.4  Recovery  and  error  correction  procedures.  This  paragraph  shall  identify  error  messages 
that  may  be  displayed  and  shall  indicate  their  meanings  and  any  corrective  actions  that  should 
be  taken.  Also  included  shall  be  any  procedures  to  be  followed  by  the  user  with  respect  to 
restart,  recovery,  and  continuity  of  operations  in  the  event  of  emergencies. 

6.5  Termination  procedures.  This  paragraph  shall  present  the  sequence  of  steps  necessary 
to  terminate  the  processing. 

7.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document.  If  section 
6  has  been  expanded  into  section(s)  1 .....  this  section  shall  be  numbered  as  the  next  section 
following  section  n. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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10.  PREPARATION  INSTRUCTIONS  —  10.2  Content  Requirements  (continued) 


Format  of  Data  Record 

ITEM  NAME 

FORMAT  • 

RANGE  OF 
VALUES 

UNIT  OF 
MEASUREMENT 

ORG-NAME 

30 

AN 

1-9, A-Z 

ORG-ID 

6 

AN 

1-9, A-Z 

SOC-SEC-NO 

9 

N 

0-9 

NAME 

20 

AN 

— 

PAY -GRADE 

4 

AN 

- — 

GROSS-PAY 

6 

SN 

0-9 

Dollars 

GROSS-PAY -YTD 

8 

SN 

0-9 

Dollars 

FED-TAX 

6 

SN 

0-9 

Dollars 

FED-TAX-YTD 

8 

SN 

0-9 

Dollars 

FICA 

6 

SN 

0-9 

Dollars 

FICA- YTD 

8 

SN 

0-9 

Dollars 

STATE-TAX 

6 

SN 

0-9 

Dollars 

STATE-TAX- YTD 

8 

SN 

0-9 

Dollars 

STATE-TAX-CODE 

2 

AN 

B3-F6 

ALLOTMENTS 

6 

SN 

0-9 

Dollars 

NET-PAY 

6 

SN 

0-9 

Dollars 

AN  =  Alphanumeric 

SN  =  Signed  Numeric 

Figure  1 .  Example  of  data  record  format. 


Preprogrammed  Query  Capabilities 
DESCRIPTION  QUERY  CODE 


Number  of  employees  within  an  organization  A 

Number  of  employees  in  a  specific  pay  grade  B 

Total  gross  pay  for  employees  within  an  C 

organization 

State  tax  year-to-date  for  specific  state  D 

FICA  tax  year-to-date  for  a  specific  employee  E 

Total  deductions  for  a  specific  employee  F 

Net  pay  for  a  specific  employee  G 


Figure  2.  Example  of  preprogrammed  query  capability. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 


Format  of  Query  A 


NUMBER  OF  EMPLOYEES  WITHIN  AN  ORGANIZATION 


QUERY  ITEM 

TITLE 

CHARACTER 

POSITION 

CONTENT/ 

COMMENT 

Query  Designator 

1 

Q 

Constant 

File  Number 

2-3 

01 

Constant 

Query  Number 

Security  Classification 

4-5 

10 

U 

Insert  01-99 
Unclassified 

Query  Card  Format  Code 
Organization 

12 

14-19 

A 

Insert  ORG-ID 
as  requested  by 
query.  Refer  to 
data  format  for 
applicable  code. 

Figure  3.  Example  of  query  format. 


Query  Statement 

Request  -  No.  of  employees  within  an  organization 
(Office  of  Secretary  of  Defense) 

Query  Statement  -  IF  ORG-ID  EQ  OSD  LIST  NO  OF  EMPLOYEES 


Figure  4.  Example  of  query  statement. 
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1.  TITLE 

SOFTWARE  INSTALLATION  PLAN  (SIP) 

3  4  »  il  iBa  iETI  JL1 ,*.]:]*  .  ■■■ 

DI-IPSC-81428 

3.1  The  Software  Installation  Plan  (SIP)  is  a  plan  for  installing  software  at  user  sites,  including 
preparations,  user  training,  and  conversion  from  existing  systems. 

3.2  The  SIP  is  developed  when  the  developer  will  be  involved  in  the  installation  of  software  at  user  sites 
and  when  the  installation  process  will  be  sufficiently  complex  to  require  a  documented  plan.  For  software 
embedded  in  a  hardware-software  system,  a  fielding  or  deployment  plan  for  the  hardware-software  system 
may  make  a  separate  SIP  unnecessary. 


4.  APPROVAL  DATE 

[  <YYMMD01  941205 

5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 

EC.  DTIC  APPLICABLE 

6b.  GIDEP  APPUCABLE 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  develop  and  record  plans  for  performing  software 
installation  and  training  at  user  sites. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-IPSC-80699. 


B.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


IONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7071 


I  fliTOlJPl  i -TOSH 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1 664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS--  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem  or  item  to  which 
the  document  applies;  contract  number;  CDRL  item  number;  organization  for  which  the 
document  has  been  prepared;  name  and  address  of  the  preparing  organization;  and 
distribution  statement.  For  data  in  a  database  or  other  alternative  form,  this  information 
shall  be  included  on  external  and  internal  labels  or  by  equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberina/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1  •  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1.3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
plan  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

1 .4  Relationship  to  other  plans.  This  paragraph  shall  describe  the  relationship,  if  any,  of  the 
SIP  to  other  project  management  plans. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  plan.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Installation  overview.  This  section  shall  be  divided  into  the  following  paragraphs  to 
provide  an  overview  of  the  installation  process. 

3.1  Description.  This  paragraph  shall  provide  a  general  description  of  the  installation  process 
to  provide  a  frame  of  reference  for  the  remainder  of  the  document.  A  list  of  sites  for  software 
installation,  the  schedule  dates,  and  the  method  of  installation  shall  be  included. 

3.2  Contact  point.  This  paragraph  shall  provide  the  organizational  name,  office  symbol/code, 
and  telephone  number  of  a  point  of  contact  for  questions  relating  to  this  installation. 

3.3  Support  materials.  This  paragraph  shall  list  the  type,  source,  and  quantity  of  support 
materials  needed  for  the  installation.  Included  shall  be  items  such  as  magnetic  tapes,  disk 
packs,  computer  printer  paper,  and  special  forms. 

3-4  Training.  This  paragraph  shall  describe  the  developer's  plans  for  training  personnel  who 
will  operate  and/or  use  the  software  installed  at  user  sites.  Included  shall  be  the  delineation 
between  general  orientation,  classroom  training,  and  "hands-on"  training. 

3.5  Tasks.  This  paragraph  shall  list  and  describe  in  general  terms  each  task  involved  in  the 
software  installation.  Each  task  description  shall  identify  the  organization  that  will  accomplish 
the  task,  usually  either  the  user,  computer  operations,  or  the  developer.  The  task  list  shall 
include  such  items  as: 

a.  Providing  overall  planning,  coordination,  and  preparation  for  installation 

b.  Providing  personnel  for  the  installation  team 
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c.  Arranging  lodging,  transportation,  and  office  facilities  for  the  installation  team 

d.  Ensuring  that  all  manuals  applicable  to  the  installation  are  available  when  needed 

e.  Ensuring  that  all  other  prerequisites  have  been  fulfilled  prior  to  the  installation 

f.  Planning  and  conducting  training  activities 

g.  Providing  students  for  the  training 

h.  Providing  computer  support  and  technical  assistance  for  the  installation 

i.  Providing  for  conversion  from  the  current  system 

3.6  Personnel.  This  paragraph  shall  describe  the  number,  type,  and  skill  level  of  the 
personnel  needed  during  the  installation  period,  including  the  need  for  multishift  operation, 
clerical  support,  etc. 

3.7  Security  and  privacy.  This  paragraph  shall  contain  an  overview  of  the  security  and 
privacy  considerations  associated  with  the  system. 

4.  Site-specific  information  for  software  center  operations  staff.  This  section  applies  if  the 
software  will  be  installed  in  computer  center(s)  or  other  centralized  or  networked  software 
installations  for  users  to  access  via  terminals  or  using  batch  inputs/outputs.  If  this  type  of 
installation  does  not  apply,  this  section  shall  contain  the  words  "Not  applicable." 

4.x  (Site  name).  This  paragraph  shall  identify  a  site  or  set  of  sites  and  shall  be  divided  into 
the  following  subparagraphs  to  discuss  those  sites.  Multiple  sites  may  be  discussed  together 
when  the  information  for  those  sites  is  generally  the  same. 

4.x.  1  Schedule.  This  paragraph  shall  present  a  schedule  of  tasks  to  be  accomplished  during 
installation.  It  shall  depict  the  tasks  in  chronological  order  with  beginning  and  ending  dates 
of  each  task  and  supporting  narrative  as  necessary. 

4.x. 2  Software  inventory.  This  paragraph  shall  provide  an  inventory  of  the  software  needed 
to  support  the  installation.  The  software  shall  be  identified  by  name,  identification  number, 
version  number,  release  number,  configuration,  and  security  classification,  as  applicable.  This 
paragraph  shall  indicate  whether  the  software  is  expected  to  be  on  site  or  will  be  delivered 
for  the  installation  and  shall  identify  any  software  to  be  used  only  to  facilitate  the  installation 
process. 

4.x. 3  Facilities.  This  paragraph  shall  detail  the  physical  facilities  and  accommodations 
needed  during  the  installation  period.  This  description  shall  include  the  following,  as 
applicable: 

% 

a.  Classroom,  work  space,  and  training  aids  needed,  specifying  hours  per  day,  number 
of  days,  and  shifts 

b.  Hardware  that  must  be  operational  and  available 

c.  Transportation  and  lodging  for  the  installation  team 
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4.x. 4  Installation  team.  This  paragraph  shall  describe  the  composition  of  the  installation 
team.  Each  team  member's  tasks  shall  be  defined. 

4.x. 5  Installation  procedures.  This  paragraph  shall  provide  step-by-step  procedures  for 
accomplishing  the  installation.  References  may  be  made  to  other  documents,  such  as 
operator  manuals.  Safety  precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included 
where  applicable.  The  procedures  shall  include  the  following,  as  applicable: 

a.  Installing  the  software 

b.  Checking  out  the  software  once  installed 

c.  Initializing  databases  and  other  software  with  site-specific  data 

d.  Conversion  from  the  current  system,  possibly  involving  running  in  parallel 

e.  Dry  run  of  the  procedures  in  operator  and  user  manuals 

4. x. 6  Data  update  procedures.  This  paragraph  shall  present  the  data  update  procedures  to 
be  followed  during  the  installation  period.  When  the  data  update  procedures  are  the  same  as 
normal  updating  or  processing  procedures,  reference  may  be  made  to  other  documents,  such 
as  operator  manuals. 

5.  Site-soecific  information  for  software  users.  This  section  shall  provide  installation 
planning  pertinent  to  users  of  the  software.  When  more  than  one  type  of  user  is  involved,  for 
example,  users  at  different  positions,  performing  different  functions,  or  in  different 
organizations,  a  separate  section  (Sections  5  through  n)  may  be  written  for  each  type  of  user 
and  the  section  titles  modified  to  reflect  each  user. 

5.x  (Site  name).  This  paragraph  shall  identify  a  site  or  set  of  sites  and  shall  be  divided  into 
the  following  subparagraphs  to  discuss  those  sites.  Multiple  sites  may  be  discussed  together 
when  the  information  for  those  sites  is  generally  the  same. 

5.x.  1  Schedule.  This  paragraph  shall  present  a  schedule  of  tasks  to  be  accomplished  by 
the  user  during  installation.  It  shall  depict  the  tasks  in  chronological  order  including  beginning 
and  ending  dates  for  each  task  and  supporting  narrative  as  necessary. 

5.x.2  Installation  procedures.  This  paragraph  shall  provide  step-by-step  procedures  for 
accomplishing  the  installation.  Reference  may  be  made  to  other  documents,  such  as  user 
manuals.  Safety  precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included  where 
applicable.  The  procedures  shall  include  the  following,  as  applicable: 

a.  Performing  the  tasks  under  4.x. 5  if  not  performed  by  operations  staff 

b.  Initializing  user-specific  data 

c.  Setting  up  queries  and  other  user  inputs 

d.  Performing  sample  processing 

e.  Generating  sample  reports 

f.  Conversion  from  the  current  system,  possibly  involving  running  in  parallel 

g.  Dry  run  of  procedures  in  user  manuals 
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5. x. 3  Data  update  procedures.  This  paragraph  shall  be  divided  into  subparagraphs  to 
present  the  user's  data  update  procedures  to  be  followed  during  the  installation  period.  When 
update  procedures  are  the  same  as  normal  processing,  reference  may  be  made  to  other 
documents,  such  as  user  manuals,  and  to  Section  4  of  this  document 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document.  If  section 
5  has  been  expanded  into  section(s)  6,...n,  this  section  shall  be  numbered  as  the  next  section 
following  section  n. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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3.  DESCRIPTION /PURPOSE 

3.1  The  Software  Product  Specification  (SPS)  contains  or  references  the  executable  software,  source  files, 
and  software  support  information,  including  "as  built’  design  information  and  compilation,  build,  and 
modification  procedures,  for  a  Computer  Software  Configuration  Item  (CSCI). 

3.2  The  SPS  can  be  used  to  order  the  executable  software  and/or  source  files  for  a  CSCI  and  is  the  primary 
software  support  document  for  the  CSCI.  Note:  Different  organizations  have  different  policies  for  ordering 
delivery  of  software.  These  policies  should  be  determined  before  applying  this  DID. 


4.  APPROVAL  DATE 

,VVMMD0'  941205 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


7.  APPLICATION/INTERRELATIONSHIP 


6a.  OTIC  APPLICABLE  I  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  prepare  executable  software,  source  files,  "as  built’ 
CSCI  design,  and/or  related  support  information  for  delivery. 

.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80029A,  DI-IPSC-80696,  and  DI-MCCR-80317. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


STRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 
N7084 


instructs 


Automated  techniques.  Use|gf  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  oaoe  or  identifier  with  signature  blocks.  The  document  shall  include  a  title  page 
containing,  as  applicable:  document  number;  volume  number;  version/revision  indicator; 
security  markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document 
title;  name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item 
to  which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing  organiza¬ 
tion;  distribution  statement;  and  signature  blocks  for  the  developer  representative 
authorized  to  release  the  document,  the  acquirer  representative  authorized  to  approve 
the  document,  and  the  dates  of  release/approval.  For  data  in  a  database  or  other 
alternative  form,  this  information  shall  be  included  on  external  and  internal  labels  or  by 
equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numbering/labeling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  specification.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Requirements.  This  section  shall  be  divided  into  the  following  paragraphs  to  achieve 
delivery  of  the  software  and  to  establish  the  requirements  that  another  body  of  software  must 
meet  to  be  considered  a  valid  copy  of  the  CSCI. 

Note:  In  past  versions  of  this  DID,  Section  3  required  a  presentation  of  the  software 
design  describing  the  "as  built"  software.  That  approach  was  modeled  on  hardware 
development,  in  which  the  product  specification  presents  the  final  design  as  the 
requirement  to  which  hardware  items  must  be  manufactured.  For  software,  however,  this 
approach  does  not  apply.  Software  "manufacturing"  consists  of  electronic  duplication  of 
the  software  itself,  not  recreation  from  design,  and  the  validity  of  a  "manufactured"  copy 
is  determined  by  comparison  to  the  software  itself,  not  to  a  design  description.  This 
section  therefore  establishes  the  software  itself  as  the  criterion  that  must  be  matched  for 
a  body  of  software  to  be  considered  a  valid  copy  of  the  CSCI.  The  updated  software 
design  has  been  placed  in  Section  5  below,  not  as  a  requirement,  but  as  information  to 
be  used  to  modify,  enhance,  or  otherwise  support  the  software.  If  any  portion  of  this 
specification  is  placed  under  acquirer  configuration  control,  it  should  be  limited  to  Section 
3.  It  is  the  software  itself  that  establishes  the  product  baseline,  not  a  description  of  the 
software's  design. 

3.1  Executable  software.  This  paragraph  shall  provide,  by  reference  to  enclosed  or  otherwise 
provided  electronic  media,  the  executable  software  for  the  CSCI,  including  any  batch  files, 
command  files,  data  files,  or  other  software  files  needed  to  install  and  operate  the  software 
on  its  target  computer(s).  In  order  for  a  body  of  software  to  be  considered  a  valid  copy  of  the 
CSCI's  executable  software,  it  must  be  shown  to  match  these  files  exactly. 

3.2  Source  files.  This  paragraph  shall  provide,  by  reference  to  enclosed  or  otherwise 
provided  electronic  media,  the  source  files  for  the  CSCI,  including  any  batch  files,  command 
files,  data  files,  or  other  files  needed  to  regenerate  the  executable  software  for  the  CSCI.  In 
order  for  a  body  of  software  to  be  considered  a  valid  copy  of  the  CSCI's  source  files,  it  must 
be  shown  to  match  these  files  exactly. 
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3.3  Packaaino  requirements.  This  paragraph  shall  state  the  requirements,  if  any,  for 
packaging  and  marking  copies  of  the  CSCI. 

4.  Qualification  provisions.  This  paragraph  shall  state  the  method(s)  to  be  used  to 
demonstrate  that  a  given  body  of  software  is  a  valid  copy  of  the  CSCI.  For  example,  the 
method  for  executable  files  might  be  to  establish  that  each  executable  file  referenced  in  3.1 
has  an  identically-named  counterpart  in  the  software  in  question  and  that  each  such 
counterpart  can  be  shown,  via  bit-for-bit  comparison,  check  sum,  or  other  method,  to  be 
identical  to  the  corresponding  executable  file.  The  method  for  source  files  might  be 
comparable,  using  the  source  files  referenced  in  3.2. 

5.  Software  support  information.  This  section  shall  be  divided  into  the  following  paragraphs 
to  provide  information  needed  to  support  the  CSCI. 

5.1  "As  built"  software  design.  This  paragraph  shall  contain,  or  reference  an  appendix  or 
other  deliverable  document  that  contains,  information  describing  the  design  of  the  "as  built” 
CSCI.  The  information  shall  be  the  same  as  that  required  in  a  Software  Design  Description 
(SDD),  Interface  Design  Description  (IDD),  and  Database  Design  Description  (DBDD),  as 
applicable.  If  these  documents  or  their  equivalents  are  to  be  delivered  for  the  "as  built”  CSCI, 
this  paragraph  shall  reference  them.  If  not,  the  information  shall  be  provided  in  this 
document.  Information  provided  in  the  headers,  comments,  and  code  of  the  source  code 
listings  may  be  referenced  and  need  not  be  repeated  in  this  section.  If  the  SDD,  IDD,  or  DBDD 
is  included  in  an  appendix,  the  paragraph  numbers  and  page  numbers  need  not  be  changed. 

5.2  Compilation/build  procedures.  This  paragraph  shall  describe,  or  reference  an  appendix 
that  describes,  the  compilation/build  process  to  be  used  to  create  the  executable  files  from 
the  source  files  and  to  prepare  the  executable  files  to  be  loaded  into  firmware  or  other 
distribution  media.  It  shall  specify  the  compiler(s)/assembler(s)  to  be  used,  including  version 
numbers;  other  hardware  and  software  needed,  including  version  numbers;  any  settings, 
options,  or  conventions  to  be  used;  and  procedures  for  compiling/assembling,  linking,  and 
building  the  CSCI  and  the  software  system/subsystem  containing  the  CSCI,  including 
variations  for  different  sites,  configurations,  versions,  etc.  Build  procedures  above  the  CSCI 
level  may  be  presented  in  one  SPS  and  referenced  from  the  others. 

5.3  Modification  procedures.  This  paragraph  shall  describe  procedures  that  must  be  followed 
to  modify  the  CSCI.  It  shall  include  or  reference  information  on  the  following,  as  applicable: 

a.  Support  facilities,  equipment,  and  software,  and  procedures  for  their  use 

b.  Databases/data  files  used  by  the  CSCI  and  procedures  for  using  and  modifying  them 

c.  Design,  coding,  and  other  conventions  to  be  followed 

d.  Compilation/build  procedures  if  different  from  those  above  ^ 

e.  Integration  and  testing  procedures  to  be  followed 

5.4  Computer  hardware  resource  utilization.  This  paragraph  shall  describe  the  "as  built" 
CSCI's  measured  utilization  of  computer  hardware  resources  (such  as  processor  capacity, 
memory  capacity,  input/output  device  capacity,  auxiliary  storage  capacity,  and 
communications/network  equipment  capacity).  It  shall  cover  all  computer  hardware  resources 


Page  _4_  of  Jj_ 


Software  Product  Specification  (SPS) 

DI-IPSC-81441 

10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 

included  in  utilization  requirements  for  the  CSCI,  in  system-level  resource  allocations  affecting 
the  CSCI,  or  in  the  software  development  plan.  If  all  utilization  data  for  a  given  computer 
hardware  resource  is  presented  in  a  single  location,  such  as  in  one  SPS,  this  paragraph  may 
reference  that  source.  Included  for  each  computer  hardware  resource  shall  be: 

a.  The  CSCI  requirements  or  system-level  resource  allocations  being  satisfied. 
(Alternatively,  the  traceability  to  CSCI  requirements  may  be  provided  in  6.c.) 

b.  The  assumptions  and  conditions  on  which  the  utilization  data  are  based  (for  example, 
typical  usage,  worst-case  usage,  assumption  of  certain  events) 

c.  Any  special  considerations  affecting  the  utilization  (such  as  use  of  virtual  memory, 
overlays,  or  multiprocessors  or  the  impacts  of  operating  system  overhead,  library 
software,  or  other  implementation  overhead) 

d.  The  units  of  measure  used  (such  as  percentage  of  processor  capacity,  cycles  per 
second,  bytes  of  memory,  kilobytes  per  second) 

e.  The  level(s)  at  which  the  estimates  or  measures  have  been  made  (such  as  software 
unit,  CSCI,  or  executable  program) 

6.  Requirements  traceability.  This  section  shall  provide: 

a.  Traceability  from  each  CSCI  source  file  to  the  software  unit(s)  that  it  implements. 

b.  Traceability  from  each  software  unit  to  the  source  files  that  implement  it. 

c.  Traceability  from  each  computer  hardware  resource  utilization  measurement  given  in 
5.4  to  the  CSCI  requirements  it  addresses.  (Alternatively,  this  traceability  may  be 
provided  in  5.4.) 

d.  Traceability  from  each  CSCI  requirement  regarding  computer  hardware  resource 
utilization  to  the  utilization  measurements  given  in  5.4. 

7.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
specification  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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1.  TITLE 

2.  IDENTIFICATION  NUMBER 

SOFTWARE  REQUIREMENTS  SPECIFICATION  (SRS) 

DI-IPSC-81433 

1  3.  DESCRIPTION  /PURPOSE 

3.1  The  Software  Requirements  Specification  (SRS)  specifies  the  requirements  for  a  Computer  Software 
Configuration  Item  (CSCI)  and  the  methods  to  be  used  to  ensure  that  each  requirement  has  been  met. 
Requirements  pertaining  to  the  CSCI's  external  interfaces  may  be  presented  in  the  SRS  or  in  one  or  more 
Interface  Requirements  Specifications  (IRSs)  (DI-IPSC-81434)  referenced  from  the  SRS. 

3.2  The  SRS,  possibly  supplemented  by  IRSs,  is  used  as  the  basis  for  design  and  qualification  testing  of  a 
CSCI. 


4.  APPROVAL  DATE  6.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

(VYMMDD>  941205  EC 


.  APPLICATION/INTERRELATIONSHIP 


6a.  DTIC  APPLICABLE  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  software  requirements  to  be 
met  by  a  CSCI. 

.3  Requirements  pertaining  to  CSCI  interfaces  may  be  presented  in  the  SRS  or  in  IRSs. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-80025A  and  DI-MCCR-80301 . 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  1 2/5/94  through  1 2/5/96 


10.  PREPARATION  INSTRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7076 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

\  (Continued  on  Page  2) 

11.  DISTRIBUTION  STATEMENT  “  - - 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier  with  signature  blocks.  The  document  shall  include  a  title  page 
containing,  as  applicable:  document  number;  volume  number;  version/revision  indicator; 
security  markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document 
title;  name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item 
to  which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing  organiza¬ 
tion;  distribution  statement;  and  signature  blocks  for  the  developer  representative 
authorized  to  release  the  document,  the  acquirer  representative  authorized  to  approve 
the  document,  and  the  dates  of  release/approval.  For  data  in  a  database  or  other 
alternative  form,  this  information  shall  be  included  on  external  and  internal  labels  or  by 
equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Paae  numberinci/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out.”  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 


Page  _2_  of  10 


Software  Requirements  Specification  (SRS) 

DI-IPSC-81433 

10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  specification.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Requirements.  This  section  shall  be  divided  into  the  following  paragraphs  to  specify  the 
CSCI  requirements,  that  is,  those  characteristics  of  the  CSCI  that  are  conditions  for  its 
acceptance.  CSCI  requirements  are  software  requirements  generated  to  satisfy  the  system 
requirements  allocated  to  this  CSCI.  Each  requirement  shall  be  assigned  a  project-unique 
identifier  to  support  testing  and  traceability  and  shall  be  stated  in  such  a  way  that  an  objective 
test  can  be  defined  for  it.  Each  requirement  shall  be  annotated  with  associated  qualification 
method(s)  (see  section  4)  and  traceability  to  system  (or  subsystem,  if  applicable)  requirements 
(see  section  5. a)  if  not  provided  in  those  sections.  The  degree  of  detail  to  be  provided  shall 
be  guided  by  the  following  rule:  Include  those  characteristics  of  the  CSCI  that  are  conditions 
for  CSCI  acceptance;  defer  to  design  descriptions  those  characteristics  that  the  acquirer  is 
willing  to  leave  up  to  the  developer.  If  there  are  no  requirements  in  a  given  paragraph,  the 
paragraph  shall  so  state.  If  a  given  requirement  fits  into  more  than  one  paragraph,  it  may  be 
stated  once  and  referenced  from  the  other  paragraphs. 

3.1  Required  states  and  modes.  If  the  CSCI  is  required  to  operate  in  more  than  one  state  or 
mode  having  requirements  distinct  from  other  states  or  modes,  this  paragraph  shall  identify 
and  define  each  state  and  mode.  Examples  of  states  and  modes  include:  idle,  ready,  active, 
post-use  analysis,  training,  degraded,  emergency,  backup,  wartime,  peacetime.  The 
distinction  between  states  and  modes  is  arbitrary.  A  CSCI  may  be  described  in  terms  of 
states  only,  modes  only,  states  within  modes,  modes  within  states,  or  any  other  scheme  that 
is  useful.  If  no  states  or  modes  are  required,  this  paragraph  shall  so  state,  without  the  need 
to  create  artificial  distinctions.  If  states  and/or  modes  are  required,  each  requirement  or  group 
of  requirements  in  this  specification  shall  be  correlated  to  the  states  and  modes.  The 
correlation  may  be  indicated  by  a  table  or  other  method  in  this  paragraph,  in  an  appendix 
referenced  from  this  paragraph,  or  by  annotation  of  the  requirements  in  the  paragraphs  where 
they  appear. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

3.2  CSCI  capability  requirements.  This  paragraph  shall  be  divided  into  subparagraphs  to 
itemize  the  requirements  associated  with  each  capability  of  the  CSCI.  A  "capability"  is 
defined  as  a  group  of  related  requirements.  The  word  "capability"  may  be  replaced  with 
"function,"  "subject,"  "object,"  or  other  term  useful  fo«  presenting  the  requirements. 

3.2.x  (CSCI  capability).  This  paragraph  shall  identify  a  required  CSCI  capability  and  shall 
itemize  the  requirements  associated  with  the  capability.  If  the  capability  can  be  more  clearly 
specified  by  dividing  it  into  constituent  capabilities,  the  constituent  capabilities  shall  be 
specified  in  subparagraphs.  The  requirements  shall  specify  required  behavior  of  the  CSCI  and 
shall  include  applicable  parameters,  such  as  response  times,  throughput  times,  other  timing 
constraints,  sequencing,  accuracy,  capacities  (how  much/how  many),  priorities,  continuous 
operation  requirements,  and  allowable  deviations  based  on  operating  conditions.  The 
requirements  shall  include,  as  applicable,  required  behavior  under  unexpected,  unallowed,  or 
"out  of  bounds"  conditions,  requirements  for  error  handling,  and  any  provisions  to  be 
incorporated  into  the  CSCI  to  provide  continuity  of  operations  in  the  event  of  emergencies. 
Paragraph  3.3.x  of  this  DID  provides  a  list  of  topics  to  be  considered  when  specifying 
requirements  regarding  inputs  the  CSCI  must  accept  and  outputs  it  must  produce. 

3.3  CSCI  external  interface  requirements.  This  paragraph  shall  be  divided  into  subparagraphs 
to  specify  the  requirements,  if  any,  for  the  CSCI's  external  interfaces.  This  paragraph  may 
reference  one  or  more  Interface  Requirements  Specifications  (IRSs)  or  other  documents 
containing  these  requirements. 

3.3.1  Interface  identification  and  diagrams.  This  paragraph  shall  identify  the  required 
external  interfaces  of  the  CSCI  (that  is,  relationships  with  other  entities  that  involve  sharing, 
providing  or  exchanging  data).  The  identification  of  each  interface  shall  include  a  project- 
unique  identifier  and  shall  designate  the  interfacing  entities  (systems,  configuration  items, 
users,  etc.)  by  name,  number,  version,  and  documentation  references,  as  applicable.  The 
identification  shall  state  which  entities  have  fixed  interface  characteristics  (and  therefore 
impose  interface  requirements  on  interfacing  entities)  and  which  are  being  developed  or 
modified  (thus  having  interface  requirements  imposed  on  them).  One  or  more  interface 
diagrams  shall  be  provided  to  depict  the  interfaces. 

3.3.x  (Proiect-uniaue  identifier  of  interface).  This  paragraph  (beginning  with  3.3.2)  shall 
identify  a  CSCI  external  interface  by  project-unique  identifier,  shall  briefly  identify  the 
interfacing  entities,  and  shall  be  divided  into  subparagraphs  as  needed  to  state  the 
requirements  imposed  on  the  CSCI  to  achieve  the  interface.  Interface  characteristics  of  the 
other  entities  involved  in  the  interface  shall  be  stated  as  assumptions  or  as  "When  [the  entity 
not  covered]  does  this,  the  CSCI  shall...,”  not  as  requirements  on  the  other  entities.  This 
paragraph  may  reference  other  documents  (such  as  data  dictionaries,  standards  for 
communication  protocols,  and  standards  for  user  interfaces)  in  place  of  stating  the  information 
here.  The  requirements  shall  include  the  following,  as  applicable,  presented  in  any  order 
suited  to  the  requirements,  and  shall  note  any  differences  in  these  characteristics  from  the 
point  of  view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
requency,  or  other  characteristics  of  data  elements): 

a.  Priority  that  the  CSCI  must  assign  the  interface 
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b.  Requirements  on  the  type  of  interface  (such  as  real-time  data  transfer,  storage-and- 
retrieval  of  data,  etc.)  to  be  implemented 

c.  Required  characteristics  of  individual  data  elements  that  the  CSCI  must  provide, 
store,  send,  access,  receive,  etc.,  such  as: 

1)  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technica!  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

d.  Required  characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays, 
displays,  reports,  etc.)  that  the  CSCI  must  provide,  store,  send,  access,  receive,  etc., 
such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and.  structure  of  data  elements/assemblies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  {setting/sending  entities)  and  recipients  (using/receiving  entities) 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

e.  Required  characteristics  of  communication  methods  that  the  CSCI  must  use  for  the 
interface,  such  as: 

1 )  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentalization,  and  auditing 

f.  Required  characteristics  of  protocols  the  CSCI  must  use  for  the  interface,  such  as: 

1 )  Project-unique  identifier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  required  characteristics,  such  as  physical  compatibility  of  the  interfacing 
entities  (dimensions,  tolerances,  loads,  plug  compatibility,  etc.),  voltages,  etc. 

3.4  CSCI  internal  interface  requirements.  This  paragraph  shall  specify  the  requirements,  if 
any,  imposed  on  interfaces  internal  to  the  CSCI.  If  all  internal  interfaces  are  left  to  the  design, 
this  fact  shall  be  so  stated.  If  such  requirements  are  to  be  imposed,  paragraph  3.3  of  this  DID 
provides  a  list  of  topics  to  be  considered. 

3.5  CSCI  internal  data  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
imposed  on  data  internal  to  the  CSCI.  Included  shall  be  requirements,  if  any,  on  databases 
and  data  files  to  be  included  in  the  CSCI.  If  all  decisions  about  internal  data  are  left  to  the 
design,  this  fact  shall  be  so  stated.  If  such  requirements  are  to  be  imposed,  paragraphs 
3.3-x.c  and  3.3.x.d  of  this  DID  provide  a  list  of  topics  to  be  considered. 

3.6  Adaptation  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
concerning  installation-dependent  data  to  be  provided  by  the  CSCI  (such  as  site-dependent 
latitude  and  longitude  or  site-dependent  state  tax  codes)  and  operational  parameters  that  the 
CSCI  is  required  to  use  that  may  vary  according  to  operational  needs  (such  as  parameters 
indicating  operation-dependent  targeting  constants  or  data  recording). 
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3.7  Safety  requirements.  This  paragraph  shall  specify  the  CSCI  requirements,  if  any, 
concerned  with  preventing  or  minimizing  unintended  hazards  to  personnel,  property,  and  the 
physical  environment.  Examples  include  safeguards  the  CSCI  must  provide  to  prevent 
inadvertent  actions  (such  as  accidentally  issuing  an  "auto  pilot  off  command)  and  non-actions 
(such  as  failure  to  issue  an  intended  "auto  pilot  off"  command).  This  paragraph  shall  include 
the  CSCI  requirements,  if  any,  regarding  nuclear  components  of  the  system,  including,  as 
applicable,  prevention  of  inadvertent  detonation  and  compliance  with  nuclear  safety  rules. 

3.8  Security  and  privacy  requirements.  This  paragraph  shall  specify  the  CSCI  requirements, 
if  any,  concerned  with  maintaining  security  and  privacy.  These  requirements  shall  include, 
as  applicable,  the  security/privacy  environment  in  which  the  CSCI  must  operate,  the  type  and 
degree  of  security  or  privacy  to  be  provided,  the  security/privacy  risks  the  CSCI  must 
withstand,  required  safeguards  to  reduce  those  risks,  the  security/privacy  policy  that  must  be 
met,  the  security/privacy  accountability  the  CSCI  must  provide,  and  the  criteria  that  must  be 
met  for  security/privacy  certification/accreditation. 

3.9  CSCI  environment  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
regarding  the  environment  in  which  the  CSCI  must  operate.  Examples  include  the  computer 
hardware  and  operating  system  on  which  the  CSCI  must  run.  (Additional  requirements 
concerning  computer  resources  are  given  in  the  next  paragraph.) 

3.10  Computer  resource  requirements.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs. 

3.10.1  Computer  hardware  requirements.  This  paragraph  shall  specify  the  requirements,  if 
any,  regarding  computer  hardware  that  must  be  used  by  the  CSCI.  The  requirements  shall 
include,  as  applicable,  number  of  each  type  of  equipment,  type,  size,  capacity,  and  other 
required  characteristics  of  processors,  memory,  input/output  devices,  auxiliary  storage, 
communications/network  equipment,  and  other  required  equipment. 

3.10.2  Computer  hardware  resource  utilization  requirements.  This  paragraph  shall  specify 
the  requirements,  if  any,  on  the  CSCI's  computer  hardware  resource  utilization,  such  as 
maximum  allowable  use  of  processor  capacity,  memory  capacity,  input/output  device 
capacity,  auxiliary  storage  device  capacity,  and  communications/network  equipment  capacity. 
The  requirements  (stated,  for  example,  as  percentages  of  the  capacity  of  each  computer 
hardware  resource)  shall  include  the  conditions,  if  any,  under  which  the  resource  utilization 
is  to  be  measured. 

3.10.3  Computer  software  requirements.  This  paragraph  shall  specify  the  requirements,  if 
any,  regarding  computer  software  that  must  be  used  by,  or  incorporated  into,  the  CSCI. 
Examples  include  operating  systems,  database  management  systems,  communications/ 
network  software,  utility  software,  input  and  equipment  simulators,  test  software,  and 
manufacturing  software.  The  correct  nomenclature,  version,  and  documentation  references 
of  each  such  software  item  shall  be  provided. 
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3.10.4  Computer  communications  requirements.  This  paragraph  shall  specify  the  additional 
requirements,  if  any,  concerning  the  computer  communications  that  must  be  used  by  the 
CSCI.  Examples  include  geographic  locations  to  be  linked;  configuration  and  network 
topology;  transmission  techniques;  data  transfer  rates;  gateways;  required  system  use  times; 
type  and  volume  of  data  to  be  transmitted/received;  time  boundaries  for  transmission/ 
reception/response;  peak  volumes  of  data;  and  diagnostic  features. 

3.11  Software  quality  factors.  This  paragraph  shall  specify  the  CSCI  requirements,  if  any, 
concerned  with  software  quality  factors  identified  in  the  contract  or  derived  from  a  higher 
level  specification.  Examples  include  quantitative  requirements  regarding  CSCI  functionality 
(the  ability  to  perform  all  required  functions),  reliability  (the  ability  to  perform  with  correct, 
consistent  results),  maintainability  (the  ability  to  be  easily  corrected),  availability  (the  ability 
to  be  accessed  and  operated  when  needed),  flexibility  (the  ability  to  be  easily  adapted  to 
changing  requirements),  portability  (the  ability  to  be  easily  modified  for  a  new  environment), 
reusability  (the  ability  to  be  used  in  multiple  applications),  testability  (the  ability  to  be  easily 
and  thoroughly  tested),  usability  (the  ability  to  be  easily  learned  and  used),  and  other 
attributes. 

3.12  Design  and  implementation  constraints.  This  paragraph  shall  specify  the  require¬ 
ments,  if  any,  that  constrain  the  design  and  implementation  of  the  CSCI.  These  requirements 
may  be  specified  by  reference  to  appropriate  commercial  or  military  standards  and 
specifications.  Examples  include  requirements  concerning: 

a.  Use  of  a  particular  CSCI  architecture  or  requirements  on  the  architecture,  such  as 
required  databases  or  other  software  units;  use  of  standard,  military,  or  existing 
components;  or  use  of  Government/acquirer-furnished  property  (equipment, 
information,  or  software) 

b.  Use  of  particular  design  or  implementation  standards;  use  of  particular  data 
standards;  use  of  a  particular  programming  language 

c.  Flexibility  and  expandability  that  must  be  provided  to  support  anticipated  areas  of 
growth  or  changes  in  technology,  threat,  or  mission 

3.1 3  Personnel-related  requirements.  This  paragraph  shall  specify  the  CSCI  requirements, 
if  any,  included  to  accommodate  the  number,  skill  levels,  duty  cycles,  training  needs,  or  other 
information  about  the  personnel  who  will  use  or  support  the  CSCI.  Examples  include 
requirements  for  number  of  simultaneous  users  and  for  built-in  help  or  training  features.  Also 
included  shall  be  the  human  factors  engineering  requirements,  if  any,  imposed  on  the  CSCI. 
These  requirements  shall  include,  as  applicable,  considerations  for  the  capabilities  and 
limitations  of  humans;  foreseeable  human  errors  under  both  normal  and  extreme  conditions; 
and  specific  areas  where  the  effects  of  human  error  would  be  particularly  serious.  Examples 
include  requirements  for  color  and  duration  of  error  messages,  physical  placement  of  critical 
indicators  or  keys,  and  use  of  auditory  signals. 

3.14  Training-related  requirements.  This  paragraph  shall  specify  the  CSCI  requirements, 
if  any,  pertaining  to  training.  Examples  include  training  software  to  be  included  in  the  CSCI. 
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3.1 5  Logistics-related  requirements.  This  paragraph  shall  specify  the  CSCI  requirements, 
if  any,  concerned  with  logistics  considerations.  These  considerations  may  include:  system 
maintenance,  software  support,  system  transportation  modes,  supply-system  requirements, 
impact  on  existing  facilities,  and  impact  on  existing  equipment. 

3.16  Other  requirements.  This  paragraph  shall  specify  additional  CSCI  requirements,  if 
any,  not  covered  in  the  previous  paragraphs. 

3.17  Packaoino  requirements.  This  section  shall  specify  the  requirements,  if  any,  for 
packaging,  labeling,  and  handling  the  CSCI  for  delivery  (for  example,  delivery  on  8  track 
magnetic  tape  labelled  and  packaged  in  a  certain  way).  Applicable  military  specifications  and 
standards  may  be  referenced  if  appropriate. 

3.18  Precedence  and  criticality  of  requirements.  This  paragraph  shall  specify,  if  applicable, 
the  order  of  precedence,  criticality,  or  assigned  weights  indicating  the  relative  importance  of 
the  requirements  in  this  specification.  Examples  include  identifying  those  requirements 
deemed  critical  to  safety,  to  security,  or  to  privacy  for  purposes  of  singling  them  out  for 
special  treatment.  If  all  requirements  have  equal  weight,  this  paragraph  shall  so  state. 

4.  Qualification  provisions.  This  section  shall  define  a  set  of  qualification  methods  and  shall 
specify  for  each  requirement  in  Section  3  the  method(s)  to  be  used  to  ensure  that  the 
requirement  has  been  met.  A  table  may  be  used  to  present  this  information,  or  each 
requirement  in  Section  3  may  be  annotated  with  the  method(s)  to  be  used.  Qualification 
methods  may  include: 

a.  Demonstration:  The  operation  of  the  CSCI,  or  a  part  of  the  CSCI,  that  relies  on 
observable  functional  operation  not  requiring  the  use  of  instrumentation,  special  test 
equipment,  or  subsequent  analysis. 

b.  Test:  The  operation  of  the  CSCI,  or  a  part  of  the  CSCI,  using  instrumentation  or 
other  special  test  equipment  to  collect  data  for  later  analysis. 

c.  Analysis:  The  processing  of  accumulated  data  obtained  from  other  qualification 
methods.  Examples  are  reduction,  interpretation,  or  extrapolation  of  test  results. 

d.  Inspection:  The  visual  examination  of  CSCI  code,  documentation,  etc. 

e.  Special  qualification  methods:  Any  special  qualification  methods  for  the  CSCI,  such 
as  special  tools,  techniques,  procedures,  facilities,  and  acceptance  limits. 

5.  Requirements  traceability.  This  paragraph  shall  contain: 

a.  Traceability  from  each  CSCI  requirement  in  this  specification  to  the  system  (or 
subsystem,  if  applicable)  requirements  it  addresses.  (Alternatively,  this  traceability 
may  be  provided  by  annotating  each  requirement  in  Section  3.) 
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Note:  Each  level  of  system  refinement  may  result  in  requirements  not  directly 
traceable  to  higher-level  requirements.  For  example,  a  system  architectural  design 
that  creates  multiple  CSCIs  may  result  in  requirements  about  how  the  CSCIs  will 
interface,  even  though  these  interfaces  are  not  covered  in  system  requirements. 
Such  requirements  may  be  traced  to  a  general  requirement  such  as  "system 
implementation"  or  to  the  system  design  decisions  that  resulted  in  their  generation. 

b.  Traceability  from  each  system  (or  subsystem,  if  applicable)  requirement  allocated  to 
this  CSCI  to  the  CSCI  requirements  that  address  it.  All  system  (subsystem) 
requirements  allocated  to  this  CSCI  shall  be  accounted  for.  Those  that  trace  to  CSCI 
requirements  contained  in  IRSs  shall  reference  those  IRSs. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
specification  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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1.  TITLE 

2.  IDENTIFICATION  NUMBER 

SYSTEM/SUBSYSTEM  DESIGN  DESCRIPTION  (SSDD) 

DI-IPSC-81432 

3.  DESCRIPTION /PURPOSE 


3.1  The  System/Subsystem  Design  Description  (SSDD)  describes  the  system-  or  subsystem-wide  design 
and  the  architectural  design  of  a  system  or  subsystem.  The  SSDD  may  be  supplemented  by  Interface 
Design  Descriptions  (IDDs)  (DI-IPSC-81436)  and  Database  Design  Descriptions  (DBDDs)  (DI-IPSC-81437) 
as  described  in  Block  7  below. 


3.2  The  SSDD,  with  its  associated  IDDs  and  DBDDs,  is  used  as  the  basis  for  further  system  development. 
Throughout  this  DID,  the  term  "system"  may  be  interpreted  to  mean  "subsystem"  as  applicable.  The 
resulting  document  should  be  titled  System  Design  Description  or  Subsystem  Design  Description  (SSDD). 


4.  APPROVAL  DATE 

B.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

6a.  DTIC  APPLICABLE 

6b.  GIDEP  APPLICABLE 

,VYMM0DI  941205 

EC 

7.  APPLICATION /INTERRELATIONSHIP 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  define  and  record  the  design  of  a  system  or  subsystem. 

..  7.3  Design  pertaining  to  interfaces  may  be  presented  in  the  SSDD  or  in  IDDs.  Design  pertaining  to 
■  databases  may  be  presented  in  the  SSDD  or  in  DBDDs. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-CM AN-80534  and  DI-MCCR-80302. 


8.  APPROVAL  LIMITATION 

9a.  APPLICABLE  FORMS 

9b.  AMSC  NUMBER 

Limited  Approval  from  12/5/94  through  12/5/96 

N7075 

10.  PRtPARAtlOif  INSTRUCTIONS 


10.1  General  instructions. 

a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

|  (Continued  on  Page  2) 

11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 

DD  Form  1664,  APR  89  Previous  editions  are  obsolete  Page  _1_  of  Pages 


136/123 


System/Subsystem  Design  Description  (SSDD) 
DI-IPSC-81432 


10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  oaoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labelino.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10*2.1.1  within  this  DID. 
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1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  Identification  of  the  system  to  which 
this  document  applies,  including,  as  applicable,  identification  number(s),  title(s),  abbrevia- 
tion(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  to  which 
this  document  applies.  It  shall  describe  the  general  nature  of  the  system;  summarize  the 
history  of  system  development,  operation,  and  maintenance;  identify  the  project  sponsor, 
acquirer,  user,  developer,  and  support  agencies;  identify  current  and  planned  operating  sites; 
and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Svstem-wide  design  decisions.  This  section  shall  be  divided  into  paragraphs  as  needed 
to  present  system-wide  design  decisions,  that  is,  decisions  about  the  system's  behavioral 
design  (how  it  will  behave,  from  a  user's  point  of  view,  in  meeting  its  requirements,  ignoring 
internal  implementation)  and  other  decisions  affecting  the  selection  and  design  of  system 
components.  If  all  such  decisions  are  explicit  in  the  requirements  or  are  deferred  to  the  design 
of  the  system  components,  this  section  shall  so  state.  Design  decisions  that  respond  to 
requirements  designated  critical,  such  as  those  for  safety,  security,  or  privacy,  shall  be  placed 
in  separate  subparagraphs.  If  a  design  decision  depends  upon  system  states  or  modes,  this 
dependency  shall  be  indicated.  Design  conventions  needed  to  understand  the  design  shall  be 
presented  or  referenced.  Examples  of  system-wide  design  decisions  are  the  following: 

a.  Design  decisions  regarding  inputs  the  system  will  accept  and  outputs  it  will  produce, 
including  interfaces  with  other  systems,  configuration  items,  and  users  (4.3.x  of  this 
DID  identifies  topics  to  be  considered  in  this  description).  If  part  or  all  of  this 
information  is  given  in  Interface  Design  Descriptions  (IDDs),  they  may  be  referenced. 

b.  Design  decisions  on  system  behavior  in  response  to  each  input  or  condition,  including 
actions  the  system  will  perform,  response  times  and  other  performance  charac¬ 
teristics,  description  of  physical  systems  modeled,  selected  equations/algorithms/ 
rules,  and  handling  of  unallowed  inputs  or  conditions. 

c.  Design  decisions  on  how  system  databases/data  files  will  appear  to  the  user  (4.3.x 
of  this  DID  identifies  topics  to  be  considered  in  this  description).  If  part  or  all  of  this 
information  is  given  in  Database  Design  Descriptions  (DBDDs),  they  may  be 
referenced. 

d.  Selected  approach  to  meeting  safety,  security,  and  privacy  requirements. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

e.  Design  and  construction  choices  for  hardware  or  hardware-software  systems,  such 
as  physical  size,  color,  shape,  weight,  materials,  and  markings. 

f.  Other  system-wide  design  decisions  made  in  response  to  requirements,  such  as 
selected  approach  to  providing  required  flexibility,  availability,  and  maintainability. 

4.  System  architectural  design.  This  section  shall  be  divided  into  the  following  paragraphs 
to  describe  the  system  architectural  design.  If  part  or  all  of  the  design  depends  upon  system 
states  or  modes,  this  dependency  shall  be  indicated.  If  design  information  falls  into  more  than 
one  paragraph,  it  may  be  presented  once  and  referenced  from  the  other  paragraphs.  Design 
conventions  needed  to  understand  the  design  shall  be  presented  or  referenced. 

Note:  For  brevity,  this  section  is  written  in  terms  of  organizing  a  system  directly  into 
Hardware  Configuration  Items  (HWCIs),  Computer  Software  Configuration  Items  (CSCIs), 
and  manual  operations,  but  should  be  interpreted  to  coyer  organizing  a  system  into 
subsystems,  organizing  a  subsystem  into  HWCIs,  CSCIs,  and  manual  operations,  or  other 
variations  as  appropriate. 

4.1  System  components.  This  paragraph  shall: 

a.  Identify  the  components  of  the  system  (HWCIs,  CSCIs,  and  manual  operations). 
Each  component  shall  be  assigned  a  project-unique  identifier.  Note:  a  database  may 
be  treated  as  a  CSCI  or  as  part  of  a  CSCI. 

b.  Show  the  static  (such  as  "consists  of")  relationship(s)  of  the  components.  Multiple 
relationships  may  be  presented,  depending  on  the  selected  design  methodology. 

c.  State  the  purpose  of  each  component  and  identify  the  system  requirements  and 
system-wide  design  decisions  allocated  to  it.  (Alternatively,  the  allocation  of 
requirements  may  be  provided  in  5. a.) 

d.  Identify  each  component's  development  status/type,  if  known  (such  as  new 
development,  existing  component  to  be  reused  as  is,  existing  design  to  be  reused  as 
is,  existing  design  or  component  to  be  reengineered,  component  to  be  developed  for 
reuse,  component  planned  for  Build  N,  etc.)  For  existing  design  or  components,  the 
description  shall  provide  identifying  information,  such  as  name,  version, 
documentation  references,  location,  etc. 

e.  For  each  computer  system  or  other  aggregate  of  computer  hardware  resources 
identified  for  use  in  the  system,  describe  its  computer  hardware  resources  (such  as 
processors,  memory,  input/output  devices,  auxiliary  storage,  and  communications/ 
network  equipment).  Each  description  shall,  as  applicable,  identify  the  configuration 
items  that  will  use  the  resource,  describe  the  allocation  of  resource  utilization  to  each 
CSCI  that  will  use  the  resource  (for  example,  20%  of  the  resource's  capacity 
allocated  to  CSCI  1 , 30%  to  CSCI  2),  describe  the  conditions  under  which  utilization 
will  be  measured,  and  describe  the  characteristics  of  the  resource: 
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1 )  Descriptions  of  computer  processors  shall  include,  as  applicable,  manufacturer 
name  and  model  number,  processor  speed/capacity,  identification  of  instruction 
set  architecture,  applicable  compiler(s),  word  size  (number  of  bits  in  each 
computer  word),  character  set  standard  (such  as  ASCII,  EBCDIC),  and  interrupt 
capabilities. 

2)  Descriptions  of  memory  shall  include,  as  applicable,  manufacturer  name  and 
model  number  and  memory  size,  type,  speed,  and  configuration  (such  as  256K 
cache  memory,  16MB  RAM  (4MB  x  4)). 

3)  Descriptions  of  input/output  devices  shall  include,  as  applicable,  manufacturer 
name  and  model  number,  type  of  device,  and  device  speed/capacity. 

4)  Descriptions  of  auxiliary  storage  shall  include,  as  applicable,  manufacturer  name 
and  model  number,  type  of  storage,  amount  of  installed  storage,  and  storage 
speed. 

5)  Descriptions  of  communications/network  equipment,  such  as  modems,  network 
interface  cards,  hubs,  gateways,  cabling,  high  speed  data  lines,  or  aggregates 
of  these  or  other  components,  shall  include,  as  applicable,  manufacturer  name 
and  model  number,  data  transfer  rates/capacities,  network  topologies, 
transmission  techniques,  and  protocols  used. 

6)  Each  description  shall  also  include,  as  applicable,  growth  capabilities,  diagnostic 
capabilities,  and  any  additional  hardware  capabilities  relevant  to  the  description. 

f.  Present  a  specification  tree  for  the  system,  that  is,  a  diagram  that  identifies  and 

shows  the  relationships  among  the  planned  specifications  for  the  system 

components. 

4.2  Concept  of  execution.  This  paragraph  shall  describe  the  concept  of  execution  among  the 
system  components.  It  shall  include  diagrams  and  descriptions  showing  the  dynamic 
relationship  of  the  components,  that  is,  how  they  will  interact  during  system  operation, 
including,  as  applicable,  flow  of  execution  control,  data  flow,  dynamically  controlled 
sequencing,  state  transition  diagrams,  timing  diagrams,  priorities  among  components,  handling 
of  interrupts,  timing/sequencing  relationships,  exception  handling,  concurrent  execution, 
dynamic  allocation/deallocation,  dynamic  creation/deletion  of  objects,  processes,  tasks,  and 
other  aspects  of  dynamic  behavior. 

4.3  Interface  design.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  interface  characteristics  of  the  system  components.  It  shall  include  both 
interfaces  among  the  components  and  their  interfaces  with  externa!  entities  such  as  other 
systems,  configuration  items,  and  users.  Note:  There  is  no  requirement  for  these  interfaces 
to  be  completely  designed  at  this  level;  this  paragraph  is  provided  to  allow  the  recording  of 
interface  design  decisions  made  as  part  of  system  architectural  design.  If  part  or  all  of  this 
information  is  contained  in  Interface  Design  Descriptions  (IDDs)  or  elsewhere,  these  sources 
may  be  referenced. 
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4.3.1  Interface  identification  and  diagrams.  This  paragraph  shall  state  the  project-unique 
identifier  assigned  to  each  interface  and  shall  identify  the  interfacing  entities  (systems, 
configuration  items,  users,  etc.)  by  name,  number,  version,  and  documentation  references, 
as  applicable.  The  identification  shall  state  which  entities  have  fixed  interface  characteristics 
(and  therefore  impose  interface  requirements  on  interfacing  entities)  and  which  are  being 
developed  or  modified  (thus  having  interface  requirements  imposed  on  them).  One  or  more 
interface  diagrams  shall  be  provided,  as  appropriate,  to  depict  the  interfaces. 

4.3.x  (Proiect-uniaue  identifier  of  interface).  This  paragraph  (beginning  with  4.3.2)  shall 
identify  an  interface  by  project-unique  identifier,  shall  briefly  identify  the  interfacing  entities, 
and  shall  be  divided  into  subparagraphs  as  needed  to  describe  the  interface  characteristics  of 
one  or  both  of  the  interfacing  entities.  If  a  given  interfacing  entity  is  not  covered  by  this 
SSDD  (for  example,  an  external  system)  but  its  interface  characteristics  need  to  be  mentioned 
to  describe  interfacing  entities  that  are,  these  characteristics  shall  be  stated  as  assumptions 
or  as  "When  [the  entity  not  covered]  does  this,  [the  entity  that  is  covered]  will  ...."  This 
paragraph  may  reference  other  documents  (such  as  data  dictionaries,  standards  for  protocols, 
and  standards  for  user  interfaces)  in  place  of  stating  the  information  here.  The  design 
description  shall  include  the  following,  as  applicable,  presented  in  any  order  suited  to  the 
information  to  be  provided,  and  shall  note  any  differences  in  these  characteristics  from  the 
point  of  view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
frequency,  or  other  characteristics  of  data  elements): 

a.  Priority  assigned  to  the  interface  by  the  interfacing  entity(ies) 

b.  Type  of  interface  (such  as  real-time  data  transfer,  storage-and-retrieval  of  data,  etc.) 

to  be  implemented 

c.  Characteristics  of  individual  data  elements  that  the  interfacing  entity(ies)  will  provide, 

store,  send,  access,  receive,  etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 

whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 
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d.  Characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays,  displays, 
reports,  etc.)  that  the  interfacing  entity(ies)  will  provide,  store,  send,  access,  receive, 
etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier  to  be  used  for  traceability 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assemblies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

e.  Characteristics  of  communication  methods  that  the  interfacing  entity(ies)  will  use  for 
the  interface,  such  as: 

1)  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentalization,  and  auditing 

f.  Characteristics  of  protocols  that  the  interfacing  entity(ies)  will  use  for  the  interface, 
such  as: 

1)  Project-unique  identifier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  characteristics,  such  as  physical  compatibility  of  the  interfacing  entity(ies) 
(dimensions,  tolerances,  loads,  voltages,  plug  compatibility,  etc.) 
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5.  Requirements  traceability.  This  paragraph  shall  contain: 

a.  Traceability  from  each  system  component  identified  in  this  SSDD  to  the  system 
requirements  allocated  to  it.  (Alternatively,  this  traceability  may  be  provided  in  4. 1 .) 

b.  Traceability  from  each  system  requirement  to  the  system  components  to  which  it  is 
allocated. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  contain  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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3.  DESCRIPTION /PURPOSE 

3.1  The  System/Subsystem  Specification  (SSS)  specifies  the  requirements  for  a  system  or  subsystem  and 
the  methods  to  be  used  to  ensure  that  each  requirement  has  been  met.  Requirements  pertaining  to  the 
system  or  subsystem's  external  interfaces  may  be  presented  in  the  SSS  or  in  one  or  more  Interface 
Requirements  Specifications  (IRSs)  (DI-lPSC-81434)  referenced  from  the  SSS. 

3.2  The  SSS,  possibly  supplemented  by  IRSs,  is  used  as  the  basis  for  design  and  qualification  testing  of  a 
system  or  subsystem.  Throughout  this  DID,  the  term  "system"  may  be  interpreted  to  mean  "subsystem"  as 
applicable.  The  resulting  document  should  be  titled  System  Specification  or  Subsystem  Specification  (SSS). 


4.  APPROVAL  DATE  5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

,VVMMDDI  941205  EC 


.  APPLICATION/INTERRELATIONSHIP 


6a.  DTIC  APPLICABLE  I  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  requirements  to  be  met  by  a 
system  or  subsystem. 

7.3  Requirements  pertaining  to  system  or  subsystem  interfaces  may  be  presented  in  the  SSS  or  in  IRSs. 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-CMAN-80008A  and  DI-IPSC-80690. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 
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9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 
N7074 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier  with  signature  blocks.  The  document  shall  include  a  title  page 
containing,  as  applicable:  document  number;  volume  number;  version/revision  indicator; 
security  markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document 
title;  name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item 
to  which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing  organiza¬ 
tion;  distribution  statement;  and  signature  blocks  for  the  developer  representative 
authorized  to  release  the  document,  the  acquirer  representative  authorized  to  approve 
the  document,  and  the  dates  of  release/approval.  For  data  in  a  database  or  other 
alternative  form,  this  information  shall  be  included  on  external  and  internal  labels  or  by 
equivalent  identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labeling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

9-  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  to  which 
this  document  applies,  including,  as  applicable,  identification  number(s),  title(s),  abbrevia- 
tion(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  to  which 
this  document  applies.  It  shall  describe  the  general  nature  of  the  system;  summarize  the 
history  of  system  development,  operation,  and  maintenance;  identify  the  project  sponsor, 
acquirer,  user,  developer,  and  support  agencies;  identify  current  and  planned  operating  sites; 
and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  specification.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Requirements.  This  section  shall  be  divided  into  the  following  paragraphs  to  specify  the 
system  requirements,  that  is,  those  characteristics  of  the  system  that  are  conditions  for  its 
acceptance.  Each  requirement  shall  be  assigned  a  project-unique  identifier  to  support  testing 
and  traceability  and  shall  be  stated  in  such  a  way  that  an  objective  test  can  be  defined  for  it. 
Each  requirement  shall  be  annotated  with  associated  qualification  method(s)  (see  section  4) 
and,  for  subsystems,  traceability  to  system  requirements  (see  section  5. a),  if  not  provided  in 
those  sections.  The  degree  of  detail  to  be  provided  shall  be  guided  by  the  following  rule: 
Include  those  characteristics  of  the  system  that  are  conditions  for  system  acceptance;  defer 
to  design  descriptions  those  characteristics  that  the  acquirer  is  willing  to  leave  up  to  the 
developer.  If  there  are  no  requirements  in  a  given  paragraph,  the  paragraph  shall  so  state. 
If  a  given  requirement  fits  into  more  than  one  paragraph,  it  may  be  stated  once  and  referenced 
from  the  other  paragraphs. 

3.1  Required  states  and  modes.  If  the  system  is  required  to  operate  in  more  than  one  state 
or  mode  having  requirements  distinct  from  other  states  or  modes,  this  paragraph  shall  identify 
and  define  each  state  and  mode.  Examples  of  states  and  modes  include:  idle,  ready,  active, 
post-use  analysis,  training,  degraded,  emergency,  backup,  wartime,  peacetime.  The 
distinction  between  states  and  modes  is  arbitrary.  A  system  may  be  described  in  terms  of 
states  only,  modes  only,  states  within  modes,  modes  within  states,  or  any  other  scheme  that 
is  useful.  If  no  states  or  modes  are  required,  this  paragraph  shall  so  state,  without  the  need 
to  create  artificial  distinctions.  If  states  and/or  modes  are  required,  each  requirement  or  group 
of  requirements  in  this  specification  shall  be  correlated  to  the  states  and  modes.  The 
correlation  may  be  indicated  by  a  table  or  other  metfl’d  in  this  paragraph,  in  an  appendix 
referenced  from  this  paragraph,  or  by  annotation  of  the  requirements  in  the  paragraphs  where 
they  appear. 
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3.2  System  capability  requirements.  This  paragraph  shall  be  divided  into  subparagraphs  to 
itemize  the  requirements  associated  with  each  capability  of  the  system.  A  "capability"  is 
defined  as  a  group  of  related  requirements.  The  word  "capability"  may  be  replaced  with 
"function,"  "subject,"  "object,"  or  other  term  useful  for  presenting  the  requirements. 

3.2.x  (System  capability).  This  paragraph  shall  identify  a  required  system  capability  and 
shall  itemize  the  requirements  associated  with  the  capability.  If  the  capability  can  be  more 
clearly  specified  by  dividing  it  into  constituent  capabilities,  the  constituent  capabilities  shall 
be  specified  in  subparagraphs.  The  requirements  shall  specify  required  behavior  of  the  system 
and  shall  include  applicable  parameters,  such  as  response  times,  throughput  times,  other 
timing  constraints,  sequencing,  accuracy,  capacities  (how  much/how  many),  priorities, 
continuous  operation  requirements,  and  allowable  deviations  based  on  operating  conditions. 
The  requirements  shall  include,  as  applicable,  required  behavior  under  unexpected,  unallowed, 
or  "out  of  bounds"  conditions,  requirements  for  error  handling,  and  any  provisions  to  be 
incorporated  into  the  system  to  provide  continuity  of  operations  in  the  event  of  emergencies. 
Paragraph  3.3.x  of  this  DID  provides  a  list  of  topics  to  be  considered  when  specifying 
requirements  regarding  inputs  the  system  must  accept  and  outputs  it  must  produce. 

3.3  System  external  interface  requirements.  This  paragraph  shall  be  divided  into  subpara¬ 
graphs  to  specify  the  requirements,  if  any,  for  the  system's  external  interfaces.  This 
paragraph  may  reference  one  or  more  Interface  Requirements  Specifications  (IRSs)  or  other 
documents  containing  these  requirements. 

3.3.1  Interface  identification  and  diagrams.  This  paragraph  shall  identify  the  required 
external  interfaces  of  the  system.  The  identification  of  each  interface  shall  include  a  project- 
unique  identifier  and  shall  designate  the  interfacing  entities  (systems,  configuration  items, 
users,  etc.)  by  name,  number,  version,  and  documentation  references,  as  applicable.  The 
identification  shall  state  which  entities  have  fixed  interface  characteristics  (and  therefore 
impose  interface  requirements  on  interfacing  entities)  and  which  are  being  developed  or 
modified  (thus  having  interface  requirements  imposed  on  them).  One  or  more  interface 
diagrams  shall  be  provided  to  depict  the  interfaces. 

3.3.x  (Proiect-uniaue  identifier  of  interface).  This  paragraph  (beginning  with  3.3.2)  shall 
identify  a  system  external  interface  by  project-unique  identifier,  shall  briefly  identify  the 
interfacing  entities,  and  shall  be  divided  into  subparagraphs  as  needed  to  state  the 
requirements  imposed  on  the  system  to  achieve  the  interface.  Interface  characteristics  of  the 
other  entities  involved  in  the  interface  shall  be  stated  as  assumptions  or  as  "When  [the  entity 
not  covered)  does  this,  the  system  shall...,"  not  as  requirements  on  the  other  entities.  This 
paragraph  may  reference  other  documents  (such  as  data  dictionaries,  standards  for 
communication  protocols,  and  standards  for  user  interfaces)  in  place  of  stating  the  information 
here.  The  requirements  shall  include  the  following,  as  applicable,  presented  in  any  order 
suited  to  the  requirements,  and  shall  note  any  differences  in  these  characteristics  from  the 
point  of  view  of  the  interfacing  entities  (such  as  different  expectations  about  the  size, 
frequency,  or  other  characteristics  of  data  elements): 

a.  Priority  that  the  system  must  assign  the  interface 
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b.  Requirements  on  the  type  of  interface  (such  as  real-time  data  transfer,  storage-and- 
retrieval  of  data,  etc.)  to  be  implemented 

c.  Required  characteristics  of  individual  data  elements  that  the  system  must  provide, 
store,  send,  access,  receive,  etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural-language)  name 

c)  DoD  standard  data  element  name 

d)  Technical  name  (e.g.,  variable  or  field  name  in  code  or  database) 

e)  Abbreviation  or  synonymous  names 

2)  Data  type  (alphanumeric,  integer,  etc.) 

3)  Size  and  format  (such  as  length  and  punctuation  of  a  character  string) 

4)  Units  of  measurement  (such  as  meters,  dollars,  nanoseconds) 

5)  Range  or  enumeration  of  possible  values  (such  as  0-99) 

6)  Accuracy  (how  correct)  and  precision  (number  of  significant  digits) 

7)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  data  element  may  be  updated  and  whether  business  rules  apply 

8)  Security  and  privacy  constraints 

9)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 

d.  Required  characteristics  of  data  element  assemblies  (records,  messages,  files,  arrays, 
displays,  reports,  etc.)  that  the  system  must  provide,  store,  send,  access,  receive, 
etc.,  such  as: 

1 )  Names/identifiers 

a)  Project-unique  identifier 

b)  Non-technical  (natural  language)  name 

c)  Technical  name  (e.g.,  record  or  data  structure  name  in  code  or  database) 

d)  Abbreviations  or  synonymous  names 

2)  Data  elements  in  the  assembly  and  their  structure  (number,  order,  grouping) 

3)  Medium  (such  as  disk)  and  structure  of  data  elements/assembiies  on  the  medium 

4)  Visual  and  auditory  characteristics  of  displays  and  other  outputs  (such  as  colors, 
layouts,  fonts,  icons  and  other  display  elements,  beeps,  lights) 

5)  Relationships  among  assemblies,  such  as  sorting/access  characteristics 

6)  Priority,  timing,  frequency,  volume,  sequencing,  and  other  constraints,  such  as 
whether  the  assembly  may  be  updated  and  whether  business  rules  apply 

7)  Security  and  privacy  constraints 

8)  Sources  (setting/sending  entities)  and  recipients  (using/receiving  entities) 
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e.  Required  characteristics  of  communication  methods  that  the  system  must  use  for  the 
interface,  such  as: 

1 )  Project-unique  identifier(s) 

2)  Communication  links/bands/frequencies/media  and  their  characteristics 

3)  Message  formatting 

4)  Flow  control  (such  as  sequence  numbering  and  buffer  allocation) 

5)  Data  transfer  rate,  whether  periodic/aperiodic,  and  interval  between  transfers 

6)  Routing,  addressing,  and  naming  conventions 

7)  Transmission  services,  including  priority  and  grade 

8)  Safety/security/privacy  considerations,  such  as  encryption,  user  authentication, 
compartmentaiization,  and  auditing 

f.  Required  characteristics  of  protocols  the  system  must  use  for  the  interface,  such  as: 

1)  Project-unique  identifier(s) 

2)  Priority/layer  of  the  protocol 

3)  Packeting,  including  fragmentation  and  reassembly,  routing,  and  addressing 

4)  Legality  checks,  error  control,  and  recovery  procedures 

5)  Synchronization,  including  connection  establishment,  maintenance,  termination 

6)  Status,  identification,  and  any  other  reporting  features 

g.  Other  required  characteristics,  such  as  physical  compatibility  of  the  interfacing 
entities  (dimensions,  tolerances,  loads,  plug  compatibility,  etc.),  voltages,  etc. 

3.4  System  internal  interface  requirements.  This  paragraph  shall  specify  the  requirements, 
if  any,  imposed  on  interfaces  internal  to  the  system.  If  all  internal  interfaces  are  left  to  the 
design  or  to  requirement  specifications  for  system  components,  this  fact  shall  be  so  stated. 
If  such  requirements  are  to  be  imposed,  paragraph  3.3  of  this  DID  provides  a  list  of  topics  to 
be  considered. 

3.5  System  internal  data  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
imposed  on  data  internal  to  the  system.  Included  shall  be  requirements,  if  any,  on  databases 
and  data  files  to  be  included  in  the  system.  If  all  decisions  about  internal  data  are  left  to  the 
design  or  to  requirements  specifications  for  system  components,  this  fact  shall  be  so  stated. 
If  such  requirements  are  to  be  imposed,  paragraphs  3.3.x.c  and  3.3.x.d  of  this  DID  provide 
a  list  of  topics  to  be  considered. 

3.6  Adaptation  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
concerning  installation-dependent  data  that  the  system  is  required  to  provide  (such  as  site- 
dependent  latitude  and  longitude  or  site-dependent  state  tax  codes)  and  operational 
parameters  that  the  system  is  required  to  use  that  may  vary  according  to  operational  needs 
(such  as  parameters  indicating  operation-dependent  targeting  constants  or  data  recording). 
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3.7  Safety  requirements.  This  paragraph  shall  specify  the  system  requirements,  if  any, 
concerned  with  preventing  or  minimizing  unintended  hazards  to  personnel,  property,  and  the 
physical  environment.  Examples  include  restricting  the  use  of  dangerous  materials;  classifying 
explosives  for  purposes  of  shipping,  handling,  and  storing;  abort/escape  provisions  from 
enclosures;  gas  detection  and  warning  devices;  grounding  of  electrical  systems;  decontamina¬ 
tion;  and  explosion  proofing.  This  paragraph  shall  include  the  system  requirements,  if  any, 
for  nuclear  components,  including,  as  applicable,  requirements  for  component  design, 
prevention  of  inadvertent  detonation,  and  compliance  with  nuclear  safety  rules. 

3.8  Security  and  privacy  requirements.  This  paragraph  shall  specify  the  system  require¬ 
ments,  if  any,  concerned  with  maintaining  security  and  privacy.  The  requirements  shall 
include,  as  applicable,  the  security/privacy  environment  in  which  the  system  must  operate, 
the  type  and  degree  of  security  or  privacy  to  be  provided,  the  security/privacy  risks  the 
system  must  withstand,  required  safeguards  to  reduce  those  risks,  the  security/privacy  policy 
that  must  be  met,  the  security/privacy  accountability  the  system  must  provide,  and  the  criteria 
that  must  be  met  for  security/privacy  certification/accreditation. 

3.9  System  environment  requirements.  This  paragraph  shall  specify  the  requirements,  if  any, 
regarding  the  environment  in  which  the  system  must  operate.  Examples  for  a  software 
system  are  the  computer  hardware  and  operating  system  on  which  the  software  must  run. 
(Additional  requirements  concerning  computer  resources  are  given  in  the  next  paragraph). 
Examples  for  a  hardware-software  system  include  the  environmental  conditions  that  the 
system  must  withstand  during  transportation,  storage,  and  operation,  such  as  conditions  in 
the  natural  environment  (wind,  rain,  temperature,  geographic  location),  the  induced 
environment  (motion,  shock,  noise,  electromagnetic  radiation),  and  environments  due  to 
enemy  action  (explosions,  radiation). 

3.10  Computer  resource  requirements.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs.  Depending  upon  the  nature  of  the  system,  the  computer  resources  covered 
in  these  subparagraphs  may  constitute  the  environment  of  the  system  (as  for  a  software 
system)  or  components  of  the  system  (as  for  a  hardware-software  system). 

3.10.1  Computer  hardware  requirements.  This  paragraph  shall  specify  the  requirements,  if 
any,  regarding  computer  hardware  that  must  be  used  by,  or  incorporated  into,  the  system. 
The  requirements  shall  include,  as  applicable,  number  of  each  type  of  equipment,  type,  size, 
capacity,  and  other  required  characteristics  of  processors,  memory,  input/output  devices, 
auxiliary  storage,  communications/network  equipment,  and  other  required  equipment. 

3.10.2  Computer  hardware  resource  utilization  requirements.  This  paragraph  shall  specify 
the  requirements,  if  any,  on  the  system's  computer  hardware  resource  utilization,  such  as 
maximum  allowable  use  of  processor  capacity,  memory  capacity,  input/output  device 
capacity,  auxiliary  storage  device  capacity,  and  communications/network  equipment  capacity. 
The  requirements  (stated,  for  example,  as  percentages  of  the  capacity  of  each  computer 
hardware  resource)  shall  include  the  conditions,  if  any,  under  which  the  resource  utilization 
is  to  be  measured. 
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3.10.3  Computer  software  requirements.  This  paragraph  shall  specify  the  requirements,  if 
any,  regarding  computer  software  that  must  be  used  by,  or  incorporated  into,  the  system. 
Examples  include  operating  systems,  database  management  systems,  communications/ 
network  software,  utility  software,  input  and  equipment  simulators,  test  software,  and 
manufacturing  software.  The  correct  nomenclature,  version,  and  documentation  references 
of  each  such  software  item  shall  be  provided. 

3. 1 0.4  Computer  communications  requirements.  This  paragraph  shall  specify  the  additional 
requirements,  if  any,  concerning  the  computer  communications  that  must  be  used  by,  or 
incorporated  into,  the  system.  Examples  include  geographic  locations  to  be  linked; 
configuration  and  network  topology;  transmission  techniques;  data  transfer  rates;  gateways; 
required  system  use  times;  type  and  volume  of  data  to  be  transmitted/received;  time 
boundaries  for  transmission/reception/response;  peak  volumes  of  data;  and  diagnostic 
features. 

3.11  System  quality  factors.  This  paragraph  shall  specify  the  requirements,  if  any, 
pertaining  to  system  quality  factors.  Examples  include  quantitative  requirements  concerning 
system  functionality  (the  ability  to  perform  all  required  functions),  reliability  (the  ability  to 
perform  with  correct,  consistent  results  --  such  as  mean  time  between  failure  for  equipment), 
maintainability  (the  ability  to  be  easily  serviced,  repaired,  or  corrected),  availability  (the  ability 
to  be  accessed  and  operated  when  needed),  flexibility  (the  ability  to  be  easily  adapted  to 
changing  requirements),  portability  of  software  (the  ability  to  be  easily  modified  for  a  new 
environment),  reusability  (the  ability  to  be  used  in  multiple  applications),  testability  (the  ability 
to  be  easily  and  thoroughly  tested),  usability  (the  ability  to  be  easily  learned  and  used),  and 
other  attributes. 

3.1 2  Desion  and  construction  constraints.  This  paragraph  shall  specify  the  requirements, 
if  any,  that  constrain  the  design  and  construction  of  the  system.  For  hardware-software 
systems,  this  paragraph  shall  include  the  physical  requirements  imposed  on  the  system. 
These  requirements  may  be  specified  by  reference  to  appropriate  commercial  or  military 
standards  and  specifications.  Examples  include  requirements  concerning: 

a.  Use  of  a  particular  system  architecture  or  requirements  on  the  architecture,  such  as 
required  subsystems;  use  of  standard,  military,  or  existing  components;  or  use  of 
Government/acquirer-furnished  property  (equipment,  information,  or  software) 

b.  Use  of  particular  design  or  construction  standards;  use  of  particular  data  standards; 
use  of  a  particular  programming  language;  workmanship  requirements  and  production 
techniques 

c.  Physical  characteristics  of  the  system  (such  as  weight  limits,  dimensional  limits, 
color,  protective  coatings);  interchangeability  of  parts;  ability  to  be  transported  from 
one  location  to  another;  ability  to  be  carried  or  set  up  by  one,  or  a  given  number  of, 
persons 

d.  Materials  that  can  and  cannot  be  used;  requirements  on  the  handling  of  toxic 
materials;  limits  on  the  electromagnetic  radiation  that  the  system  is  permitted  to 
generate 
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e.  Use  of  nameplates,  part  marking,  serial  and  lot  number  marking,  and  other  identifying 
markings 

f.  Flexibility  and  expandability  that  must  be  provided  to  support  anticipated  areas  of 
growth  or  changes  in  technology,  threat,  or  mission 

3.13  Personnel-related  requirements.  This  paragraph  shall  specify  the  system  require¬ 
ments,  if  any,  included  to  accommodate  the  number,  skill  levels,  duty  cycles,  training  needs, 
or  other  information  about  the  personnel  who  will  use  or  support  the  system.  Examples 
include  requirements  for  the  number  of  work  stations  to  be  provided  and  for  built-in  help  and 
training  features.  Also  included  shall  be  the  human  factors  engineering  requirements,  if  any, 
imposed  on  the  system.  These  requirements  shall  include,  as  applicable,  considerations  for 
the  capabilities  and  limitations  of  humans,  foreseeable  human  errors  under  both  normal  and 
extreme  conditions,  and  specific  areas  where  the  effects  of  human  error  would  be  particularly 
serious.  Examples  include  requirements  for  adjustable-height  work  stations,  color  and  duration 
of  error  messages,  physical  placement  of  critical  indicators  or  buttons,  and  use  of  auditory 
signals. 

3.14  Training-related  requirements.  This  paragraph  shall  specify  the  system  requirements, 
if  any,  pertaining  to  training.  Examples  include  training  devices  and  training  materials  to  be 
included  in  the  system. 

3.15  Logistics-related  requirements.  This  paragraph  shall  specify  the  system  requirements, 
if  any,  concerned  with  logistics  considerations.  These  considerations  may  include:  system 
maintenance,  software  support,  system  transportation  modes,  supply-system  requirements, 
impact  on  existing  facilities,  and  impact  on  existing  equipment. 

3.16  Other  requirements.  This  paragraph  shall  specify  additional  system  requirements,  if 
any,  not  covered  in  the  previous  paragraphs.  Examples  include  requirements  for  system 
documentation,  such  as  specifications,  drawings,  technical  manuals,  test  plans  and 
procedures,  and  installation  instruction  data,  if  not  covered  in  other  contractual  documents. 

3.17  Packaging  requirements.  This  section  shall  specify  the  requirements,  if  any,  for 
packaging,  labeling,  and  handling  the  system  and  its  components  for  delivery.  Applicable 
military  specifications  and  standards  may  be  referenced  if  appropriate. 

3.18  Precedence  and  criticality  of  requirements.  This  paragraph  shall  specify,  if  applicable, 
the  order  of  precedence,  criticality,  or  assigned  weights  indicating  the  relative  importance  of 
the  requirements  in  this  specification.  Examples  include  identifying  those  requirements 
deemed  critical  to  safety,  to  security,  or  to  privacy  for  purposes  of  singling  them  out  for 
special  treatment.  If  all  requirements  have  equal  weight,  this  paragraph  shall  so  state. 

4.  Qualification  provisions.  This  section  shall  define  a  set  of  qualification  methods  and  shall 
specify  for  each  requirement  in  Section  3  the  method(s)  to  be  used  to  ensure  that  the  require¬ 
ment  has  been  met.  A  table  may  be  used  to  present  this  information,  or  each  requirement  in 
Section  3  may  be  annotated  with  the  method(s)  to  be  used.  Qualification  methods  may 
include: 
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a.  Demonstration:  The  operation  of  the  system,  or  a  part  of  the  system,  that  relies  on 
observable  functional  operation  not  requiring  the  use  of  instrumentation,  special  test 
equipment,  or  subsequent  analysis. 

b.  Test:  The  operation  of  the  system,  or  a  part  of  the  system,  using  instrumentation  or 
other  special  test  equipment  to  collect  data  for  later  analysis. 

c.  Analysis:  The  processing  of  accumulated  data  obtained  from  other  qualification 
methods.  Examples  are  reduction,  interpolation,  or  extrapolation  of  test  results. 

d.  Inspection:  The  visual  examination  of  system  components,  documentation,  etc. 

e.  Special  qualification  methods.  Any  special  qualification  methods  for  the  system, 
such  as  special  tools,  techniques,  procedures,  facilities,  acceptance  limits,  use  of 
standard  samples,  preproduction  or  periodic  production  samples,  pilot  models,  or  pilot 
lots. 

5.  Requirements  traceability.  For  system-level  specifications,  this  paragraph  does  not  apply. 

For  subsystem-level  specifications,  this  paragraph  shall  contain: 

a.  Traceability  from  each  subsystem  requirement  in  this  specification  to  the  system 
requirements  it  addresses.  (Alternatively,  this  traceability  may  be  provided  by 
annotating  each  requirement  in  Section  3.) 

Note:  Each  level  of  system  refinement  may  result  in  requirements  not  directly 
traceable  to  higher-level  requirements.  For  example,  a  system  architectural  design 
that  creates  two  subsystems  may  result  in  requirements  about  how  the  subsystems 
will  interface,  even  though  these  interfaces  are  not  covered  in  system  requirements. 
Such  requirements  may  be  traced  to  a  general  requirement  such  as  "system 
implementation"  or  to  the  system  design  decisions  that  resulted  in  their  generation. 

b.  Traceability  from  each  system  requirement  that  has  been  allocated  to  the  subsystem 
covered  by  this  specification  to  the  subsystem  requirements  that  address  it.  All 
system  requirements  allocated  to  the  subsystem  shall  be  accounted  for.  Those  that 
trace  to  subsystem  requirements  contained  in  IRSs  shall  reference  those  IRSs. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  contain  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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SOFTWARE  TEST  DESCRIPTION  (STD) 


DI-IPSC-81439 


3.  DESCRIPTION  /PURPOSE 


3.1  The  Software  Test  Description  {STD)  describes  the  test  preparations,  test  cases,  and  test  procedures 
to  be  used  to  perform  qualification  testing  of  a  Computer  Software  Configuration  Item  {CSCD  or  a  software 
system  or  subsystem. 

3.2  The  STD  enables  the  acquirer  to  assess  the  adequacy  of  the  qualification  testing  to  be  performed. 


4.  APPROVAL  DATE 
(vymmdoi  94  t  205 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


6a.  DTIC  APPLICABLE  6b.  6IDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  define  and  record  the  test  preparations,  test  cases, 
kand  test  procedures  to  be  used  for  CSCI  qualification  testing  or  for  system  qualification  testing  of  a 
'software  system. 

7.3  The  Contract  Data  Requirements  List  {CDRL)  {DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-8001 5A  and  DI-MCCR-80310. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


INSTRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7082 


liiTiJTTOir.TTl 


Automated  techniques,  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b-  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 

11.  DISTRIBUTION  STATEMENT  - - - 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 


Page  J_  of  7_  Pages 


Software  Test  Description  (STD) 
DI-IPSC-81439 


10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  oaae  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberino/labelino.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1  •  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1.3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Test  preparations.  This  section  shall  be  divided  into  the  following  paragraphs.  Safety 
precautions,  marked  by  WARNING  or  CAUTION,  and  security  and  privacy  considerations  shall 
be  included  as  applicable. 

3.x  (Proiect-uniaue  identifier  of  a  test).  This  paragraph  shall  identify  a  test  by  project-unique 
identifier,  shall  provide  a  brief  description,  and  shall  be  divided  into  the  following  subpara¬ 
graphs.  When  the  information  required  duplicates  information  previously  specified  for  another 
test,  that  information  may  be  referenced  rather  than  repeated. 

3.x.  1  Hardware  preparation.  This  paragraph  shall  describe  the  procedures  necessary  to 
prepare  the  hardware  for  the  test.  Reference  may  be  made  to  published  operating  manuals 
for  these  procedures.  The  following  shall  be  provided,  as  applicable: 

a.  The  specific  hardware  to  be  used,  identified  by  name  and,  if  applicable,  number 

b.  Any  switch  settings  and  cabling  necessary  to  connect  the  hardware 

c.  One  or  more  diagrams  to  show  hardware,  interconnecting  control,  and  data  paths 

d.  Step-by-step  instructions  for  placing  the  hardware  in  a  state  of  readiness 

3.x. 2  Software  preparation.  This  paragraph  shall  describe  the  procedures  necessary  to 
prepare  the  item(s)  under  test  and  any  related  software,  including  data,  for  the  test. 
Reference  may  be  made  to  published  software  manuals  for  these  procedures.  The  following 
information  shall  be  provided,  as  applicable: 

a.  The  specific  software  to  be  used  in  the  test 

b.  The  storage  medium  of  the  item(s)  under  test  (e.g.,  magnetic  tape,  diskette) 

c.  The  storage  medium  of  any  related  software  (e.g.,  simulators,  test  drivers,  databases) 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

d.  Instructions  for  loading  the  software,  including  required  sequence 

e.  Instructions  for  software  initialization  common  to  more  than  one  test  case 

3. x. 3  Other  pre-test  preparations.  This  paragraph  shall  describe  any  other  pre-test 

personnel  actions,  preparations,  or  procedures  necessary  to  perform  the  test. 

4.  Test  descriptions.  This  section  shall  be  divided  into  the  following  paragraphs.  Safety 
precautions,  marked  by  WARNING  or  CAUTION,  and  security  and  privacy  considerations  shall 
be  included  as  applicable. 

4.x  (Proiect-uniaue  identifier  of  a  test).  This  paragraph  shall  identify  a  test  by  project-unique 
identifier  and  shall  be  divided  into  the  following  subparagraphs.  When  the  required 
information  duplicates  information  previously  provided,  that  information  may  be  referenced 
rather  than  repeated. 

4.x.y  (Proiect-uniaue  identifier  of  a  test  case).  This  paragraph  shall  identify  a  test  case  by 
project-unique  identifier,  state  its  purpose,  and  provide  a  brief  description.  The  following 
subparagraphs  shall  provide  a  detailed  description  of  the  test  case. 

4.x.y.1  Requirements  addressed.  This  paragraph  shall  identify  the  CSCI  or  system  require¬ 
ments  addressed  by  the  test  case.  (Alternatively,  this  information  may  be  provided  in  5. a.) 

4.x.y.2  Prerequisite  conditions.  This  paragraph  shall  identify  any  prerequisite  conditions  that 
must  be  established  prior  to  performing  the  test  case.  The  following  considerations  shall  be 
discussed,  as  applicable: 

a.  Hardware  and  software  configuration 

b.  Flags,  initial  breakpoints,  pointers,  control  parameters,  or  initial  data  to  be  set/reset 
prior  to  test  commencement 

c.  Preset  hardware  conditions  or  electrical  states  necessary  to  run  the  test  case 

d.  Initial  conditions  to  be  used  in  making  timing  measurements 

e.  Conditioning  of  the  simulated  environment 

f.  Other  special  conditions  peculiar  to  the  test  case 

4.x.y.3  Test  inputs.  This  paragraph  shall  describe  the  test  inputs  necessary  for  the  test  case. 
The  following  shall  be  provided,  as  applicable: 

a.  Name,  purpose,  and  description  (e.g.,  range  of  values,  accuracy)  of  each  test  input 

b.  Source  of  the  test  input  and  the  method  to  be  used  for  selecting  the  test  input 

c.  Whether  the  test  input  is  real  or  simulated 

d.  Time  or  event  sequence  of  test  input 

e.  The  manner  in  which  the  input  data  will  be  controlled  to: 
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10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 

1)  Test  the  item(s)  with  a  minimum/reasonable  number  of  data  types  and  values 

2)  Exercise  the  item(s)  with  a  range  of  valid  data  types  and  values  that  test  for 
overload,  saturation,  and  other  "worst  case"  effects 

3)  Exercise  the  item(s)  with  invalid  data  types  and  values  to  test  for  appropriate 
handling  of  irregular  inputs 

4)  Permit  retesting,  if  necessary 

4.x. y. 4  Expected  test  results.  This  paragraph  shall  identify  all  expected  test  results  for  the 
test  case.  Both  intermediate  and  final  test  results  shall  be  provided,  as  applicable. 

4.x.y.5  Criteria  for  evaluating  results.  This  paragraph  shall  identify  the  criteria  to  be  used  for 
evaluating  the  intermediate  and  final  results  of  the  test  case.  For  each  test  result,  the 
following  information  shall  be  provided,  as  applicable: 

a.  The  range  or  accuracy  over  which  an  output  can  vary  and  still  be  acceptable 

b.  Minimum  number  of  combinations  or  alternatives  of  input  and  output  conditions  that 
constitute  an  acceptable  test  result 

c.  Maximum/minimum  allowable  test  duration,  in  terms  of  time  or  number  of  events 

d.  Maximum  number  of  interrupts,  halts,  or  other  system  breaks  that  may  occur 

e.  Allowable  severity  of  processing  errors 

f.  Conditions  under  which  the  result  is  inconclusive  and  re-testing  is  to  be  performed 

g.  Conditions  under  which  the  outputs  are  to  be  interpreted  as  indicating  irregularities 
in  input  test  data,  in  the  test  database/data  files,  or  in  test  procedures 

h.  Allowable  indications  of  the  control,  status,  and  results  of  the  test  and  the  readiness 
for  the  next  test  case  (may  be  output  of  auxiliary  test  software) 

i.  Additional  criteria  not  mentioned  above. 

4.x.y.6  Test  procedure.  This  paragraph  shall  define  the  test  procedure  for  the  test  case.  The 
test  procedure  shall  be  defined  as  a  series  of  individually  numbered  steps  listed  sequentially 
in  the  order  in  which  the  steps  are  to  be  performed.  For  convenience  in  document 
maintenance,  the  test  procedures  may  be  included  as  an  appendix  and  referenced  in  this 
paragraph.  The  appropriate  level  of  detail  in  each  test  procedure  depends  on  the  type  of 
software  being  tested.  For  some  software,  each  keystroke  may  be  a  separate  test  procedure 
step;  for  most  software,  each  step  may  include  a  logically  related  series  of  keystrokes  or  other 
actions.  The  appropriate  level  of  detail  is  the  level  at  which  it  is  useful  to  specify  expected 
results  and  compare  them  to  actual  results.  The  following  shall  be  provided  for  each  test 
procedure,  as  applicable: 

a.  Test  operator  actions  and  equipment  operation  required  for  each  step,  including 
commands,  as  applicable,  to: 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 )  Initiate  the  test  case  and  apply  test  inputs 

2)  Inspect  test  conditions 

3)  Perform  interim  evaluations  of  test  results 

4)  Record  data 

5)  Halt  or  interrupt  the  test  case 

6)  Request  data  dumps  or  other  aids,  if  needed 

7)  Modify  the  database/data  files 

8)  Repeat  the  test  case  if  unsuccessful 

9)  Apply  alternate  modes  as  required  by  the  test  case 

10)  Terminate  the  test  case 

b.  Expected  result  and  evaluation  criteria  for  each  step 

c.  If  the  test  case  addresses  multiple  requirements,  identification  of  which  test 
procedure  step(s)  address  which  requirements.  (Alternatively,  this  information  may 
be  provided  in  5.) 

d.  Actions  to  follow  in  the  event  of  a  program  stop  or  indicated  error,  such  as: 

1 )  Recording  of  critical  data  from  indicators  for  reference  purposes 

2)  Halting  or  pausing  time-sensitive  test-support  software  and  test  apparatus 

3)  Collection  of  system  and  operator  records  of  test  results 

e.  Procedures  to  be  used  to  reduce  and  analyze  test  results  to  accomplish  the  following, 
as  applicable: 

1 )  Detect  whether  an  output  has  been  produced 

2)  Identify  media  and  location  of  data  produced  by  the  test  case 

3)  Evaluate  output  as  a  basis  for  continuation  of  test  sequence 

4)  Evaluate  test  output  against  required  output 

4. x.y.7  Assumptions  and  constraints.  This  paragraph  shall  identify  any  assumptions  made 
and  constraints  or  limitations  imposed  in  the  description  of  the  test  case  due  to  system  or  test 
conditions,  such  as  limitations  on  timing,  interfaces,  equipment,  personnel,  and  database/data 
files.  If  waivers  or  exceptions  to  specified  limits  and  parameters  are  approved,  they  shall  be 
identified  and  this  paragraph  shall  address  their  effects  and  impacts  upon  the  test  case. 

5.  Requirements  traceability.  This  paragraph  shall  contain: 

a.  Traceability  from  each  test  case  in  this  STD  to  the  system  or  CSCI  requirements  it 
addresses.  If  a  test  case  addresses  multiple  requirements,  traceability  from  each  set 
of  test  procedure  steps  to  the  requirement(s)  addressed.  (Alternatively,  this 
traceability  may  be  provided  in  4.x.y.1.) 
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10.  PREPARATION  INSTRUCTIONS  —  10.2  Content  Requirements  (continued) 

b.  Traceability  from  each  system  or  CSCI  requirement  covered  by  this  STD  to  the  test 
case(s)  that  address  it.  For  CSCI  testing,  traceability  from  each  CSCI  requirement  in 
the  CSCI's  Software  Requirements  Specification  (SRS)  and  associated  Interface 
Requirements  Specifications  (IRSs).  For  system  testing,  traceability  from  each 
system  requirement  in  the  system's  System/Subsystem  Specification  (SSS)  and 
associated  IRSs.  If  a  test  case  addresses  multiple  requirements,  the  traceability  shall 
indicate  the  particular  test  procedure  steps  that  address  each  requirement. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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ENTIFICATION  N 


SOFTWARE  TEST  PLAN  (STP) 


DI-IPSC-81438 


3.  DESCRIPTION  /PURPOSE 

3.1  The  Software  Test  Plan  (STP)  describes  plans  for  qualification  testing  of  Computer  Software 
Configuration  Items  (CSCIs)  and  software  systems.  It  describes  the  software  test  environment  to  be  used 
for  the  testing,  identifies  the  tests  to  be  performed,  and  provides  schedules  for  test  activities. 

3.2  There  is  usually  a  single  STP  for  a  project.  The  STP  enables  the  acquirer  to  assess  the  adequacy  of 
planning  for  CSCI  and,  if  applicable,  software  system  qualification  testing. 


n-ratrar*  iriTTuryifa: 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


RELATIONS  HI 


6a.  DTIC  APPLICABLE  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  develop  and  record  plans  for  conducting  CSCI 
qualification  testing  and/or  system  qualification  testing  of  a  software  system. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80014A,  DI-IPSC-80697,  DI-MCCR-80307,  DI-MCCR-80308,  and 
DI-MCCR-80309. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


lift  iJTiT.'l  f:irw  flilTt 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7081 


jnstructic 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  page  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberina/labelina.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

1.4  Relationship  to  other  plans.  This  paragraph  shall  describe  the  relationship,  if  any,  of  the 
STP  to  related  project  management  plans. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  plan.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Software  test  environment.  This  section  shall  be  divided  into  the  following  paragraphs 
to  describe  the  software  test  environment  at  each  intended  test  site.  Reference  may  be  made 
to  the  Software  Development  Plan  (SDP)  for  resources  that  are  described  there. 

3.x  (Name  of  test  site(s)).  This  paragraph  shall  identify  one  or  more  test  sites  to  be  used  for 
the  testing,  and  shall  be  divided  into  the  following  subparagraphs  to  describe  the  software  test 
environment  at  the  site(s).  If  all  tests  will  be  conducted  at  a  single  site,  this  paragraph  and 
its  subparagraphs  shall  be  presented  only  once.  If  multiple  test  sites  use  the  same  or  similar 
software  test  environments,  they  may  be  discussed  together.  Duplicative  information  among 
test  site  descriptions  may  be  reduced  by  referencing  earlier  descriptions. 

3.x.  1  Software  items.  This  paragraph  shall  identify  by  name,  number,  and  version,  as 
applicable,  the  software  items  (e.g.,  operating  systems,  compilers,  communications  software, 
related  applications  software,  databases,  input  files,  code  auditors,  dynamic  path  analyzers, 
test  drivers,  preprocessors,  test  data  generators,  test  control  software,  other  special  test 
software,  post-processors)  necessary  to  perform  the  planned  testing  activities  at  the  test 
site(s).  This  paragraph  shall  describe  the  purpose  of  each  item,  describe  its  media  (tape,  disk, 
etc.),  identify  those  that  are  expected  to  be  supplied  by  the  site,  and  identify  any  classified 
processing  or  other  security  or  privacy  issues  associated  with  the  software  items. 

3.x. 2  Hardware  and  firmware  items.  This  paragraph  shall  identify  by  name,  number,  and 
version,  as  applicable,  the  computer  hardware,  interfacing  equipment,  communications 
equipment,  test  data  reduction  equipment,  apparatus  such  as  extra  peripherals  (tape  drives, 
printers,  plotters),  test  message  generators,  test  timing  devices,  test  event  records,  etc.,  and 
firmware  items  that  will  be  used  in  the  software  test  environment  at  the  test  site(s).  This 
paragraph  shall  describe  the  purpose  of  each  item,  state  the  period  of  usage  and  the  number 


Page  _3_  of 


Software  Test  Plan  (STP) 

DI-IPSC-81438 

10.  PREPARATION  INSTRUCTIONS--  10.2  Content  Requirements  (continued) 

of  each  item  needed,  identify  those  that  are  expected  to  be  supplied  by  the  site,  and  identify 
any  classified  processing  or  other  security  or  privacy  issues  associated  with  the  items. 

3.x. 3  Other  materials.  This  paragraph  shall  identify  and  describe  any  other  materials 
needed  for  the  testing  at  the  test  site(s).  These  materials  may  include  manuals,  software 
listings,  media  containing  the  software  to  be  tested,  media  containing  data  to  be  used  in  the 
tests,  sample  listings  of  outputs,  and  other  forms  or  instructions.  This  paragraph  shall  identify 
those  items  that  are  to  be  delivered  to  the  site  and  those  that  are  expected  to  be  supplied  by 
the  site.  The  description  shall  include  the  type,  layout,  and  quantity  of  the  materials,  as 
applicable.  This  paragraph  shall  identify  any  classified  processing  or  other  security  or  privacy 
issues  associated  with  the  items. 

3.x. 4  Proprietary  nature,  acquirer's  rights,  and  licensing.  This  paragraph  shall  identify  the 
proprietary  nature,  acquirer's  rights,  and  licensing  issues  associated  with  each  element  of  the 
software  test  environment. 

3.x. 5  Installation,  testino,  and  control.  This  paragraph  shall  identify  the  developer's  plans 
for  performing  each  of  the  following,  possibly  in  conjunction  with  personnel  at  the  test  site(s): 

a.  Acquiring  or  developing  each  element  of  the  software  test  environment 

b.  Installing  and  testing  each  item  of  the  software  test  environment  prior  to  its  use 

c.  Controlling  and  maintaining  each  item  of  the  software  test  environment 

3.x. 6  Participating  organizations.  This  paragraph  shall  identify  the  organizations  that  will 
participate  in  the  testing  at  the  test  sites(s)  and  the  roles  and  responsibilities  of  each. 

3.X.7  Personnel.  This  paragraph  shall  identify  the  number,  type,  and  skill  level  of  personnel 
needed  during  the  test  period  at  the  test  site(s),  the  dates  and  times  they  will  be  needed,  and 
any  special  needs,  such  as  multishift  operation  and  retention  of  key  skills  to  ensure  continuity 
and  consistency  in  extensive  test  programs. 

3.x.8  Orientation  plan.  This  paragraph  shall  describe  any  orientation  and  training  to  be 
given  before  and  during  the  testing.  This  information  shall  be  related  to  the  personnel  needs 
given  in  3.x. 7.  This  training  may  include  user  instruction,  operator  instruction,  maintenance 
and  control  group  instruction,  and  orientation  briefings  to  staff  personnel.  If  extensive  training 
is  anticipated,  a  separate  plan  may  be  developed  and  referenced  here. 

3. x. 9  Tests  to  be  performed.  This  paragraph  shall  identify,  by  referencing  section  4,  the 

tests  to  be  performed  at  the  test  site(s). 

4.  Test  identification.  This  section  shall  be  divided  into  the  following  paragraphs  to  identify 
and  describe  each  test  to  which  this  STP  applies. 

4.1  General  information.  This  paragraph  shall  be  divided  into  subparagraphs  to  present 
general  information  applicable  to  the  overall  testing  to  be  performed. 

4.1.1  Test  levels.  This  paragraph  shall  describe  the  levels  at  which  testing  will  be 
performed,  for  example,  CSCI  level  or  system  level. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

4. 1 .2  Test  classes.  This  paragraph  shall  describe  the  types  or  classes  of  tests  that  will  be 
performed  (for  example,  timing  tests,  erroneous  input  tests,  maximum  capacity  tests). 

4. 1 .3  General  test  conditions.  This  paragraph  shall  describe  conditions  that  apply  to  all  of 
the  tests  or  to  a  group  of  tests.  For  example:  "Each  test  shall  include  nominal,  maximum, 
and  minimum  values;"  "each  test  of  type  x  shall  use  live  data;"  "execution  size  and  time  shall 
be  measured  for  each  CSCI."  Included  shall  be  a  statement  of  the  extent  of  testing  to  be 
performed  and  rationale  for  the  extent  selected.  The  extent  of  testing  shall  be  expressed  as 
a  percentage  of  some  well  defined  total  quantity,  such  as  the  number  of  samples  of  discrete 
operating  conditions  or  values,  or  other  sampling  approach.  Also  included  shall  be  the 
approach  to  be  followed  for  retesting/regression  testing. 

4.1.4  Test  progression.  In  cases  of  progressive  or  cumulative  tests,  this  paragraph  shall 
explain  the  planned  sequence  or  progression  of  tests. 

4.1.5  Data  recording,  reduction,  and  analysis.  This  paragraph  shall  identify  and  describe 
the  data  recording,  reduction,  and  analysis  procedures  to  be  used  during  and  after  the  tests 
identified  in  this  STP.  These  procedures  shall  include,  as  applicable,  manual,  automatic,  and 
semi-automatic  techniques  for  recording  test  results,  manipulating  the  raw  results  into  a  form 
suitable  for  evaluation,  and  retaining  the  results  of  data  reduction  and  analysis. 

4.2  Planned  tests.  This  paragraph  shall  be  divided  into  the  following  subparagraphs  to 
describe  the  total  scope  of  the  planned  testing. 

4.2. x  (Item(s)  to  be  tested).  This  paragraph  shall  identify  a  CSCI,  subsystem,  system,  or 
other  entity  by  name  and  project-unique  identifier,  and  shall  be  divided  into  the  following  sub- 
paragraphs  to  describe  the  testing  planned  for  the  item(s).  (Note:  the  "tests"  in  this  plan  are 
collections  of  test  cases.  There  is  no  intent  to  describe  each  test  case  in  this  document.) 

4.2. x.y  (Proiect-unioue  identifier  of  a  test).  This  paragraph  shall  identify  a  test  by  project-uni¬ 
que  identifier  and  shall  provide  the  information  specified  below  for  the  test.  Reference  may 
be  made  as  needed  to  the  genera!  information  in  4.1 . 

a.  Test  objective 

b.  Test  level 

c.  Test  type  or  class 

d.  Qualification  method(s)  as  specified  in  the  requirements  specification 

e.  Identifier  of  the  CSCI  requirements  and,  if  applicable,  software  system  requirements 
^  addressed  by  this  test.  (Alternatively,  this  information  may  be  provided  in  Section  6.) 

f.  Special  requirements  (for  example,  48  hours  of  continuous  facility  time,  weapon 
simulation,  extent  of  test,  use  of  a  special  input  or  database) 

g.  Type  of  data  to  be  recorded 

h.  Type  of  data  recording/reduction/analysis  to  be  employed 
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10.  PREPARATION  INSTRUCTIONS  -  10.2  Content  Requirements  (continued) 

i.  Assumptions  and  constraints,  such  as  anticipated  limitations  on  the  test  due  to 
system  or  test  conditions-timing,  interfaces,  equipment,  personnel,  database,  etc. 

j.  Safety,  security,  and  privacy  considerations  associated  with  the  test 

5.  Test  schedules.  This  section  shall  contain  or  reference  the  schedules  for  conducting  the 
tests  identified  in  this  plan.  It  shall  include: 

a.  A  listing  or  chart  depicting  the  sites  at  which  the  testing  will  be  scheduled  and  the 
time  frames  during  which  the  testing  will  be  conducted 

b.  A  schedule  for  each  test  site  depicting  the  activities  and  events  listed  below,  as 
applicable,  in  chronological  order  with  supporting  narrative  as  necessary: 

1)  On-site  test  period  and  periods  assigned  to  major  portions  of  the  testing 

2)  Pretest  on-site  period  needed  for  setting  up  the  software  test  environment  and 
other  equipment,  system  debugging,  orientation,  and  familiarization 

3)  Collection  of  database/data  file  values,  input  values,  and  other  operational  data 
needed  for  the  testing 

4)  Conducting  the  tests,  including  planned  retesting 

5)  Preparation,  review,  and  approval  of  the  Software  Test  Report  (STR) 

6.  Requirements  traceability.  This  paragraph  shall  contain: 

a.  Traceability  from  each  test  identified  in  this  plan  to  the  CSCI  requirements  and,  if 
applicable,  software  system  requirements  it  addresses.  (Alternatively,  this 
traceability  may  be  provided  in  4.2.x.y  and  referenced  from  this  paragraph.) 

b.  Traceability  from  each  CSCI  requirement  and,  if  applicable,  each  software  system 
requirement  covered  by  this  test  plan  to  the  test(s)  that  address  it.  The  traceability 
shall  cover  the  CSCI  requirements  in  all  applicable  Software  Requirements 
Specifications  (SRSs)  and  associated  Interface  Requirements  Specifications  (IRSs), 
and,  for  software  systems,  the  system  requirements  in  all  applicable  System/ 
Subsystem  Specifications  (SSSs)  and  associated  system-level  IRSs. 

7.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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3.  DESCRIPTION /PURPOSE 

3.1  The  Software  Test  Report  (STR)  is  a  record  of  the  qualification  testing  performed  on  a  Computer 
Software  Configuration  Item  (CSCI),  a  software  system  or  subsystem,  or  other  software-related  item. 

3.2  The  STR  enables  the  acquirer  to  assess  the  testing  and  its  results. 
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RELATIONSHIP 


6«.  DTIC  APPLICABLE  I  6b.  6IDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  analyze  and  record  the  results  of  CSCI  qualification 
testing,  system  qualification  testing  of  a  software  system,  or  other  testing  identified  in  the  contract. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-8001 7A,  DI-IPSC-80698,  and  DI-MCCR-8031 1 . 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


CTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7083 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  paae  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labeling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  reouirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 

% 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scooe.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  report.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Overview  of  test  results.  This  section  shall  be  divided  into  the  following  paragraphs  to 
provide  an  overview  of  test  results. 

3.1  Overall  assessment  of  the  software  tested.  This  paragraph  shall: 

a.  Provide  an  overall  assessment  of  the  software  as  demonstrated  by  the  test  results 
in  this  report 

b.  Identify  any  remaining  deficiencies,  limitations,  or  constraints  that  were  detected  by 
the  testing  performed.  Problem/change  reports  may  be  used  to  provide  deficiency 
information. 

c.  For  each  remaining  deficiency,  limitation,  or  constraint,  describe: 

1)  Its  impact  on  software  and  system  performance,  including  identification  of 
requirements  not  met 

2)  The  impact  on  software  and  system  design  to  correct  it 

3)  A  recommended  solution/approach  for  correcting  it 

3.2  Impact  of  test  environment.  This  paragraph  shall  provide  an  assessment  of  the  manner 
in  which  the  test  environment  may  be  different  from  the  operational  environment  and  the 
effect  of  this  difference  on  the  test  results. 

3.3  Recommended  improvements.  This  paragraph  shall  provide  any  recommended 
improvements  in  the  design,  operation,  or  testing  of  the  software  tested.  A  discussion  of 
each  recommendation  and  its  impact  on  the  software  may  be  provided.  If  no  recommended 
improvements  are  provided,  this  paragraph  shall  state  "None." 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

4.  Detailed  test  results.  This  section  shall  be  divided  into  the  following  paragraphs  to 
describe  the  detailed  results  for  each  test.  Note:  The  word  "test"  means  a  related  collection 
of  test  cases. 

4.x  (Project-unique  identifier  of  a  test).  This  paragraph  shall  identify  a  test  by  project-unique 
identifier  and  shall  be  divided  into  the  following  subparagraphs  to  describe  the  test  results. 

4.x.  1  Summary  of  test  results.  This  paragraph  shall  summarize  the  results  of  the  test.  The 
summary  shall  include,  possibly  in  a  table,  the  completion  status  of  each  test  case  associated 
with  the  test  (for  example,  "all  results  as  expected,"  "problems  encountered,"  "deviations 
required").  When  the  completion  status  is  not  "as  expected,"  this  paragraph  shall  reference 
the  following  paragraphs  for  details. 

4.x. 2  Problems  encountered.  This  paragraph  shall  be  divided  into  subparagraphs  that 
identify  each  test  case  in  which  one  or  more  problems  occurred. 

4.x.2.y  (Proiect-uniaue  identifier  of  a  test  case).  This  paragraph  shall  identify  by  project- 
unique  identifier  a  test  case  in  which  one  or  more  problems  occurred,  and  shall  provide: 

a.  A  brief  description  of  the  problem(s)  that  occurred 

b.  Identification  of  the  test  procedure  step(s)  in  which  they  occurred 

c.  Reference(s)  to  the  associated  problem/change  report(s)  and  backup  data,  as 
applicable 

d.  The  number  of  times  the  procedure  or  step  was  repeated  in  attempting  to  correct  the 
problem(s)  and  the  outcome  of  each  attempt 

e.  Back-up  points  or  test  steps  where  tests  were  resumed  for  retesting 

4.x. 3  Deviations  from  test  cases/procedures.  This  paragraph  shall  be  divided  into  subpara¬ 
graphs  that  identify  each  test  case  in  which  deviations  from  test  case/test  procedures 
occurred. 

4.x.3.y  (Project-unique  identifier  of  a  test  case).  This  paragraph  shall  identify  by  project- 
unique  identifier  a  test  case  in  which  one  or  more  deviations  occurred,  and  shall  provide: 

a.  A  description  of  the  deviation(s)  (for  example,  test  case  run  in  which  the  deviation 
occurred  and  nature  of  the  deviation,  such  as  substitution  of  required  equipment, 
procedural  steps  not  followed,  schedule  deviations).  (Red-lined  test  procedures  may 
be  used  to  show  the  deviations) 

b.  The  rationale  for  the  deviation(s) 

c.  An  assessment  of  the  deviations'  impact  on  the  validity  of  the  test  case 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

5.  Test  log.  This  section  shall  present,  possibly  in  a  figure  or  appendix,  a  chronological 
record  of  the  test  events  covered  by  this  report.  This  test  log  shall  include: 

a.  The  date(s),  time(s),  and  location(s)  of  the  tests  performed 

b.  The  hardware  and  software  configurations  used  for  each  test  including,  as  applicable, 
part/model/serial  number,  manufacturer,  revision  level,  and  calibration  date  of  all 
hardware,  and  version  number  and  name  for  the  software  components  used 

c.  The  date  and  time  of  each  test-related  activity,  the  identity  of  the  individual(s)  who 
performed  the  activity,  and  the  identities  of  witnesses,  as  applicable 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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sources,  gathering  end  meinteintng  the  dete  needed  end  completing  and  reviewing  the  c  of  faction  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aepect 
of  this  collection  of  information,  including  suggestions  for  reducing  this  burden  to  Washington  Headquarters  Services,  Directorate  of  Operations  end  Reports,  1216  Jefferson  Dave 
Highway,  Suite  1204,  Arlington,  VA  22202*4302,  end  to  the  Office  of  Management  end  Budget,  Paperwork  Reduction  Project  10704*0188),  Washington  ,  DC  20603. 


SOFTWARE  TRANSITION  PLAN  (STrP) 


3.  DESCRIPTION /PURPOSE 


3.1  The  Software  Transition  Plan  (STrP)  identifies  the  hardware,  software,  and  other  resources  needed  for 
life  cycle  support  of  deliverable  software  and  describes  the  developer's  plans  for  transitioning  deliverable 
items  to  the  support  agency. 

3.2  The  STrP  is  developed  if  the  software  support  concept  calls  for  transition  of  responsibility  from  the 
developer  to  a  separate  support  agency.  The  STrP  may  also  be  used  by  the  acquirer  for  updating  the 
Computer  Resources  Life  Cycle  Management  Plan. 


4.  APPROVAL  DATE 
(YYMMDDI  941205 


S.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

EC 


APPLICATION /INTERRELATIONSHIP 


6a.  DTIC  APPLICABLE  I  6b.  GIDEP  APPLICABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  develop  and  record  plans  for  transitioning  deliverable 
items  to  the  support  agency. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80024A. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  1 2/5/94  through  1 2/5/96 


ION  INSTRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7072 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

_  (Continued  on  Page  2) 


1 1 .  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 
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10.  PREPARATION  INSTRUCTIONS  --  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Paoe  numberinq/labelinq.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1 .  Scone.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

1 .4  Relationship  to  other  plans.  This  paragraph  shall  describe  the  relationship,  if  any,  of  the 
STrP  to  other  project  management  plans. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Software  support  resources.  This  section  shall  be  divided  into  paragraphs  to  identify  and 
describe  the  resources  needed  to  support  the  deliverable  software.  These  resources  shall 
include  items  needed  to  control,  copy,  and  distribute  the  software  and  its  documentation,  and 
to  specify,  design,  implement,  document,  test,  evaluate,  control,  copy,  and  distribute 
modifications  to  the  software. 

3-1  Facilities.  This  paragraph  shall  describe  the  facilities  needed  to  support  the  deliverable 
software.  These  facilities  may  include  special  buildings,  rooms,  mock-ups,  building  features 
such  as  raised  flooring  or  cabling;  building  features  to  support  security  and  privacy 
requirements  (TEMPEST  shielding,  vaults,  etc.),  building  features  to  support  safety 
requirements  (smoke  alarms,  safety  glass,  etc.),  special  power  requirements,  and  so  on.  The 
purpose  of  each  item  shall  be  described.  Diagrams  may  be  included  as  applicable. 

3.2  Hardware.  This  paragraph  shall  identify  and  describe  the  hardware  and  associated 
documentation  needed  to  support  the  deliverable  software.  This  hardware  may  include 
computers,  peripheral  equipment,  hardware  simulators,  stimulators,  emulators,  diagnostic 
equipment,  and  non-computer  equipment.  The  description  shall  include: 

a.  Specific  models,  versions,  and  configurations 

b.  Rationale  for  the  selected  hardware 

c.  Reference  to  user/operator  manuals  or  instructions  for  each  item,  as  applicable 

d.  Identification  of  each  hardware  item  and  document  as  acquirer-furnished,  an  item  that 
will  be  delivered  to  the  support  agency,  an  item  the  support  agency  is  known  to 
have,  an  item  the  support  agency  must  acquire,  or  other  description  of  status 
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10,  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

e.  If  items  must  be  acquired,  information  about  a  current  source  of  supply,  including 
whether  the  item  is  currently  available  and  whether  it  is  expected  to  be  available  at 
the  time  of  delivery 

f .  Information  about  manufacturer  support,  licensing,  and  data  rights,  including  whether 
the  item  is  currently  supported  by  the  manufacturer,  whether  it  is  expected  to  be 
supported  at  the  time  of  delivery,  whether  licenses  will  be  assigned  to  the  support 
agency,  and  the  terms  of  such  licenses 

g.  Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

3.3  Software.  This  paragraph  shall  identify  and  describe  the  software  and  associated 
documentation  needed  to  support  the  deliverable  software.  This  software  may  include 
computer-aided  software  engineering  (CASE)  tools,  data  in  these  tools,  compilers,  test  tools, 
test  data,  simulations,  emulations,  utilities,  configuration  management  tools,  databases  and 
data  files,  and  other  software.  The  description  shall  include: 

a.  Specific  names,  identification  numbers,  version  numbers,  release  numbers,  and 
configurations,  as  applicable 

b.  Rationale  for  the  selected  software 

c.  Reference  to  user/operator  manuals  or  instructions  for  each  item,  as  applicable 

d.  Identification  of  each  software  item  and  document  as  acquirer-furnished,  an  item  that 
will  be  delivered  to  the  support  agency,  an  item  the  support  agency  is  known  to 
have,  an  item  the  support  agency  must  acquire,  or  other  description  of  status 

e.  If  items  must  be  acquired,  information  about  a  current  source  of  supply,  including 
whether  the  item  is  currently  available  and  whether  it  is  expected  to  be  available  at 
the  time  of  delivery 

f.  Information  about  vendor  support,  licensing,  and  data  rights,  including  whether  the 
item  is  currently  supported  by  the  vendor,  whether  it  is  expected  to  be  supported  at 
the  time  of  delivery,  whether  licenses  will  be  assigned  to  the  support  agency,  and  the 
terms  of  such  licenses 

g.  Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

3.4  Other  documentation.  This  paragraph  shall  identify  any  other  documentation  needed  to 
support  the  deliverable  software.  The  list  will  include,  for  example,  plans,  reports,  studies, 
specifications,  design  descriptions,  test  cases/procedures,  test  reports,  user/operator  manuals, 
and  support  manuals  for  the  deliverable  software.  This  paragraph  shall  provide: 

a.  Names,  identification  numbers,  version  numbers,  and  release  numbers,  as  applicable 

b.  Rationale  for  including  each  document  in  the  list 

c.  Identification  of  each  document  as  acquirer-furnished,  an  item  that  will  be  delivered 
to  the  support  agency,  an  item  the  support  agency  is  known  to  have,  an  item  the 
support  agency  must  acquire,  or  other  description  of  status 

d.  If  a  document  must  be  acquired,  information  about  where  to  acquire  it 
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e.  Information  about  licensing  and  data  rights 

f.  Security  and  privacy  considerations,  limitations,  or  other  items  of  interest 

3.5  Personnel.  This  paragraph  shall  describe  the  personnel  needed  to  support  the  deliverable 
software,  including  anticipated  number  of  personnel,  types  and  levels  of  skills  and  expertise, 
and  security  clearances.  This  paragraph  shall  cite,  as  applicable,  actual  staffing  on  the 
development  project  as  a  basis  for  the  staffing  needs  cited. 

3.6  Other  resources.  This  paragraph  shall  identify  any  other  resources  needed  to  support  the 
deliverable  software.  Included  may  be  consumables  such  as  magnetic  tapes  and  diskettes, 
together  with  an  estimate  of  the  type  and  number  that  should  be  acquired. 

3.7  Interrelationship  of  components.  This  paragraph  shall  identify  the  interrelationships  of 
the  components  identified  in  the  preceding  paragraphs.  A  figure  may  be  used  to  show  the 
interrelationships. 

4.  Recommended  procedures.  This  section  shall  be  divided  into  paragraphs  as  needed  to 
describe  any  procedures,  including  advice  and  lessons  learned,  that  the  developer  may  wish 
to  recommend  to  the  support  agency  for  supporting  the  deliverable  software  and  associated 
support  environment. 

5.  Training.  This  section  shall  be  divided  into  paragraphs  as  appropriate  to  describe  the 
developer's  plans  for  training  support  personnel  to  support  of  the  deliverable  software.  This 
section  shall  include: 

a.  The  schedule,  duration,  and  location  for  the  training 

b.  The  delineation  between  classroom  training  and  "hands-on"  training 

c.  Provision  (either  directly  or  by  reference)  for: 

1)  Familiarization  with  the  operational  software  and  target  computer(s) 

2)  Familiarization  with  the  support  software  and  host  system 

6.  Anticipated  areas  of  change.  This  section  shall  describe  anticipated  areas  of  change  to 
the  deliverable  software. 

7.  Transition  planning.  This  section  shall  be  divided  into  paragraphs  as  needed  to  describe 
the  developer's  plans  for  transitioning  the  deliverable  software  to  the  support  agency.  This 
section  shall  address  the  following: 

a.  All  activities  to  be  performed  to  transition  the  deliverable  software  to  the  support 
agency.  These  activities  may  include  planning/coordination  meetings;  preparation  of 
items  to  be  delivered  to  the  support  agency;  packaging,  shipment,  installation,  and 
checkout  of  the  software  support  environment;  packaging,  shipment,  installation,  and 
checkout  of  the  operational  software;  and  training  of  support  personnel. 

b.  Roles  and  responsibilities  for  each  activity 
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c.  The  resources  needed  to  carry  out  the  transition  activities  and  the  source  from  which 
each  resource  will  be  provided 

d.  Schedules  and  milestones  for  conducting  the  transition  activities.  These  schedules 
and  milestones  shall  be  compatible  with  the  contract  master  schedule. 

e.  Procedures  for  installation  and  checkout  of  deliverable  items  in  the  support 
environment 

8.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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3.  DESCRIPTION/PURPOSE 

3.1  The  Software  User  Manual  (SUM)  tells  a  hands-on  software  user  how  to  install  and  use  a  Computer 
Software  Configuration  Item  (CSCI),  a  group  of  related  CSCIs,  or  a  software  system  or  subsystem.  It  may 
also  cover  a  particular  aspect  of  software  operation,  such  as  instructions  for  a  particular  position  or  task. 

3.2  The  SUM  is  developed  for  software  that  is  run  by  the  user  and  has  a  user  interface  requiring  on-line 
user  input  or  interpretation  of  displayed  output.  If  the  software  is  embedded  in  a  hardware-software 
system,  user  manuals  or  operating  procedures  for  that  system  may  make  separate  SUMs  unnecessary. 


4.  APPROVAL  DATE  5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

°"MMD0’  941205  EC 


.  APPLICATION/INTERRELATIONSHIP 


6a.  DTIC  APPLICABLE  I  6b.  GIDEP  APPUCABLE 


7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  information  needed  by  hands-on 
users  of  software. 

7.3  The  SUM  is  an  alternative  to  the  Software  Input/Output  Manual  (SIOM)  (DI-IPSC-81445)  and  Software 
Center  Operator  Manual  (SCOM)  (DI-IPSC-81444). 

7.4  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.5  This  DID  supersedes  DI-MCCR-8001 9A,  DI-IPSC-80694,  DI-MCCR-8031 3,  DI-MCCR-8031 4,  and 
DI-MCCR-8031 5. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


STRUCTIONS 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7086 


I3:14:W:T-W«V 


Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document"  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 


b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


1 1 .  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 

135/123 


Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  paoe  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents  and  index.  The  document  shall  contain  a  table  of  contents  providing 
the  number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix, 
and  an  index  providing  an  alphabetic  listing  of  key  terms  and  concepts  covered  in  the 
document  and  the  pages  or  paragraphs  in  which  the  terms  or  concepts  are  covered. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberino/labelino.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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1  •  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s). 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
manual  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  manual.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Software  summary.  This  section  shall  be  divided  into  the  following  paragraphs. 

3.1  Software  application.  This  paragraph  shall  provide  a  brief  description  of  the  intended 
uses  of  the  software.  Capabilities,  operating  improvements,  and  benefits  expected  from  its 
use  shall  be  described. 

3.2  Software  inventory.  This  paragraph  shall  identify  all  software  files,  including  databases 
and  data  files,  that  must  be  installed  for  the  software  to  operate.  The  identification  shall 
include  security  and  privacy  considerations  for  each  file  and  identification  of  the  software 
necessary  to  continue  or  resume  operation  in  case  of  an  emergency. 

3.3  Software  environment.  This  paragraph  shall  identify  the  hardware,  software,  manual 
operations,  and  other  resources  needed  for  a  user  to  install  and  run  the  software.  Included, 
as  applicable,  shall  be  identification  of: 

a.  Computer  equipment  that  must  be  present,  including  amount  of  memory  needed, 
amount  of  auxiliary  storage  needed,  and  peripheral  equipment  such  as  printers  and 
other  input/output  devices 

b.  Communications  equipment  that  must  be  present 

c.  Other  software  that  must  be  present,  such  as  operating  systems,  databases,  data 
files,  utilities,  and  other  supporting  systems 

d.  Forms,  procedures,  or  other  manual  operations  that  must  be  present 

e.  Other  facilities,  equipment,  or  resources  that  must  be  present 

3.4  Software  organization  and  overview  of  operation.  This  paragraph  shall  provide  a  brief 
description  of  the  organization  and  operation  of  the  software  from  the  user's  point  of  view. 
The  description  shall  include,  as  applicable: 


Page  3  of  6 


Software  User  Manual  (SUM) 

DI-IPSC-81443 

10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

a.  Logical  components  of  the  software,  from  the  user's  point  of  view,  and  an  overview 
of  the  purpose/operation  of  each  component 

b.  Performance  characteristics  that  can  be  expected  by  the  user,  such  as: 

1)  Types,  volumes,  rate  of  inputs  accepted 

2)  Types,  volume,  accuracy,  rate  of  outputs  that  the  software  can  produce 

3)  Typical  response  time  and  factors  that  affect  it 

4)  Typical  processing  time  and  factors  that  affect  it 

5)  Limitations,  such  as  number  of  events  that  can  be  tracked 

6)  Error  rate  that  can  be  expected 

7)  Reliability  that  can  be  expected 

c.  Relationship  of  the  functions  performed  by  the  software  with  interfacing  systems, 
organizations,  or  positions 

d.  Supervisory  controls  that  can  be  implemented  (such  as  passwords)  to  manage  the 
software 

3.5  Contingencies  and  alternate  states  and  modes  of  operation.  This  paragraph  shall  explain 
differences  in  what  the  user  will  be  able  to  do  with  the  software  at  times  of  emergency  and 
in  various  states  and  modes  of  operation,  if  applicable. 

3.6  Security  and  privacy.  This  paragraph  shall  contain  an  overview  of  the  security  and 
privacy  considerations  associated  with  the  software.  A  warning  shall  be  included  regarding 
making  unauthorized  copies  of  software  or  documents,  if  applicable. 

3.7  Assistance  and  problem  reporting.  This  paragraph  shall  identify  points  of  contact  and 
procedures  to  be  followed  to  obtain  assistance  and  report  problems  encountered  in  using  the 
software. 

4.  Access  to  the  software.  This  section  shall  contain  step-by-step  procedures  oriented  to 
the  first  time/occasional  user.  Enough  detail  shall  be  presented  so  that  the  user  can  reliably 
access  the  software  before  learning  the  details  of  its  functional  capabilities.  Safety 
precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included  where  applicable. 

4.1  First-time  user  of  the  software.  This  paragraph  shall  be  divided  into  the  following 
subparagraphs. 

4.1.1  Eouipment  familiarization.  This  paragraph  shall  describe  the  following  as  appropriate: 

a.  Procedures  for  turning  on  power  and  making  adjustments 

b.  Dimensions  and  capabilities  of  the  visual  display  screen 

c.  Appearance  of  the  cursor,  how  to  identify  an  active  cursor  if  more  than  one  cursor 
can  appear,  how  to  position  a  cursor,  and  how  to  use  a  cursor 

d.  Keyboard  layout  and  role  of  different  types  of  keys  and  pointing  devices 

e.  Procedures  for  turning  power  off  if  special  sequencing  of  operations  is  needed 
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4. 1 .2  Access  control.  This  paragraph  shall  present  an  overview  of  the  access  and  security 
features  of  the  software  that  are  visible  to  the  user.  The  following  items  shall  be  included, 
as  applicable: 

a.  How  and  from  whom  to  obtain  a  password 

b.  How  to  add,  delete,  or  change  passwords  under  user  control 

c.  Security  and  privacy  considerations  pertaining  to  the  storage  and  marking  of  output 
reports  and  other  media  that  the  user  will  generate 

4.1.3  Installation  and  setup.  This  paragraph  shall  describe  any  procedures  that  the  user 
must  perform  to  be  identified  or  authorized  to  access  or  install  software  on  the  equipment, 
to  perform  the  installation,  to  configure  the  software,  to  delete  or  overwrite  former  files  or 
data,  and  to  enter  parameters  for  software  operation. 

4.2  Initiating  a  session.  This  paragraph  shall  provide  step-by-step  procedures  for  beginning 
work,  including  any  options  available.  A  checklist  for  problem  determination  shall  be  included 
in  case  difficulties  are  encountered. 

4.3  Stopping  and  suspending  work.  This  paragraph  shall  describe  how  the  user  can  cease 
or  interrupt  use  of  the  software  and  how  to  determine  whether  normal  termination  or 
cessation  has  occurred. 

5.  Processing  reference  guide.  This  section  shall  provide  the  user  with  procedures  for  using 
the  software.  If  procedures  are  complicated  or  extensive,  additional  Sections  6,  7,  ...  may 
be  added  in  the  same  paragraph  structure  as  this  section  and  with  titles  meaningful  to  the 
sections  selected.  The  organization  of  the  document  will  depend  on  the  characteristics  of  the 
software  being  documented.  For  example,  one  approach  is  to  base  the  sections  on  the 
organizations  in  which  users  work,  their  assigned  positions,  their  work  sites,  or  the  tasks  they 
must  perform.  For  other  software,  it  may  be  more  appropriate  to  have  Section  5  be  a  guide 
to  menus.  Section  6  be  a  guide  to  the  command  language  used,  and  Section  7  be  a  guide  to 
functions.  Detailed  procedures  are  intended  to  be  presented  in  subparagraphs  of  paragraph 
5.3.  Depending  on  the  design  of  the  software,  the  subparagraphs  might  be  organized  on  a 
function-by-function,  menu-by-menu,  transaction-by-transaction,  or  other  basis.  Safety 
precautions,  marked  by  WARNING  or  CAUTION,  shall  be  included  where  applicable. 

5.1  Capabilities.  This  paragraph  shall  briefly  describe  the  interrelationships  of  the  transac¬ 
tions,  menus,  functions,  or  other  processes  in  order  to  provide  an  overview  of  the  use  of  the 
software. 

5.2  Conventions.  This  paragraph  shall  describe  any  conventions  used  by  the  software,  such 
as  the  use  of  colors  in  displays,  the  use  of  audible  alarms,  the  use  of  abbreviated  vocabulary, 
and  the  use  of  rules  for  assigning  names  or  codes. 

5.3  Processing  procedures.  This  paragraph  shall  explain  the  organization  of  subsequent 
paragraphs,  e.g.,  by  function,  by  menu,  by  screen.  Any  necessary  order  in  which  procedures 
must  be  accomplished  shall  be  described. 
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10.  PREPARATION  INSTRUCTIONS  *-  10.2  Content  Requirements  (continued) 

5.3.x  (Aspect  of  software  use).  The  title  of  this  paragraph  shall  identify  the  function, 
menu,  transaction,  or  other  process  being  described.  This  paragraph  shall  describe  and  give 
options  and  examples,  as  applicable,  of  menus,  graphical  icons,  data  entry  forms,  user  inputs, 
inputs  from  other  software  or  hardware  that  may  affect  the  software's  interface  with  the 
user,  outputs,  diagnostic  or  error  messages  or  alarms,  and  help  facilities  that  can  provide  on¬ 
line  descriptive  or  tutorial  information.  The  format  for  presenting  this  information  can  be 
adapted  to  the  particular  characteristics  of  the  software,  but  a  consistent  style  of  presentation 
shall  be  used,  i.e.,  the  descriptions  of  menus  shall  be  consistent,  the  descriptions  of 
transactions  shall  be  consistent  among  themselves. 

5.4  Related  processing.  This  paragraph  shall  identify  and  describe  any  related  batch,  offline, 
or  background  processing  performed  by  the  software  that  is  not  invoked  directly  by  the  user 
and  is  not  described  in  paragraph  5.3.  Any  user  responsibilities  to  support  this  processing 
shall  be  specified. 

5.5  Data  backup.  This  paragraph  shall  describe  procedures  for  creating  and  retaining  backup 
data  that  can  be  used  to  replace  primary  copies  of  data  in  event  of  errors,  defects, 
malfunctions,  or  accidents. 

5.6  Recovery  from  errors,  malfunctions,  and  emergencies.  This  paragraph  shall  present 
detailed  procedures  for  restart  or  recovery  from  errors  or  malfunctions  occurring  during 
processing  and  for  ensuring  continuity  of  operations  in  the  event  of  emergencies. 

5.7  Messages.  This  paragraph  shall  list,  or  refer  to  an  appendix  that  lists,  all  error  messages, 
diagnostic  messages,  and  information  messages  that  can  occur  while  accomplishing  any  of 
the  user's  functions.  The  meaning  of  each  message  and  the  action  that  should  be  taken  after 
each  such  message  shall  be  identified  and  described. 

5.8  Quick-reference  guide.  If  appropriate  to  the  software,  this  paragraph  shall  provide  or 
reference  a  quick-reference  card  or  page  for  using  the  software.  This  quick-reference  guide 
shall  summarize,  as  applicable,  frequently-used  function  keys,  control  sequences,  formats, 
commands,  or  other  aspects  of  software  use. 

6.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  terms  and  definitions  needed  to  understand  this  document.  If  section 
5  has  been  expanded  into  section(s)  6,  ...,  this  section  shall  be  numbered  as  the  next  section 
following  section  n. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 
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1  TITLE 

SOFTWARE  VERSION  DESCRIPTION  (SVD) 

raKfflHIJEHII  1  1  Ml  1  I  1  — 

DI-IPSC-81442 

3.1  The  Software  Version  Description  (SVD)  identifies  and  describes  a  software  version  consisting  of  one 
or  more  Computer  Software  Configuration  Items  (CSCIs).  It  is  used  to  release,  track,  and  control  software 
versions. 

3.2  The  term  'version”  may  be  applied  to  the  initial  release  of  the  software,  to  a  subsequent  release  of 
that  software,  or  to  one  of  multiple  forms  of  the  software  released  at  approximately  the  same  time  (for 
example,  to  different  sites). 


5.  OFFICE  OF  PRIMARY  RESPONSIBILITY 

6a.  DTIC  APPLICABLE 

EC 

4.  APPROVAL  DATE 
OTYMMDDI  941205 


7.  APPLICATION /INTERRELATIONSHIP 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation  instructions  for  the  data 
product  generated  by  specific  and  discrete  task  requirements  as  delineated  in  the  contract. 

7.2  This  DID  is  used  when  the  developer  is  tasked  to  identify  and  record  the  exact  version  of  software  to 
be  delivered  to  a  user,  support,  or  other  site. 

7.3  The  Contract  Data  Requirements  List  (CDRL)  (DD  1423)  should  specify  whether  deliverable  data  are  to 
be  delivered  on  paper  or  electronic  media;  are  to  be  in  a  given  electronic  form  (such  as  ASCII,  CALS,  or 
compatible  with  a  specified  word  processor  or  other  support  software);  may  be  delivered  in  developer 
format  rather  than  in  the  format  specified  herein;  and  may  reside  in  a  computer-aided  software  engineering 
(CASE)  or  other  automated  tool  rather  than  in  the  form  of  a  traditional  document. 

7.4  This  DID  supersedes  DI-MCCR-80013A,  and  DI-MCCR-8031 2. 


8.  APPROVAL  LIMITATION 

Limited  Approval  from  12/5/94  through  12/5/96 


flWima  fiTtlH  JTiTTCl 


9a.  APPLICABLE  FORMS 


9b.  AMSC  NUMBER 

N7085 


a.  Automated  techniques.  Use  of  automated  techniques  is  encouraged.  The  term  "document”  in  this 
DID  means  a  collection  of  data  regardless  of  its  medium. 

b.  Alternate  presentation  styles.  Diagrams,  tables,  matrices,  and  other  presentation  styles  are 
acceptable  substitutes  for  text  when  data  required  by  this  DID  can  be  made  more  readable  using 
these  styles. 

(Continued  on  Page  2) 


11.  DISTRIBUTION  STATEMENT 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release;  distribution  is  unlimited. 


DD  Form  1664,  APR  89 
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Previous  editions  are  obsolete 
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10.  PREPARATION  INSTRUCTIONS  -  10.1  General  Instructions  (continued) 

c.  Title  oaae  or  identifier.  The  document  shall  include  a  title  page  containing,  as 
applicable:  document  number;  volume  number;  version/revision  indicator;  security 
markings  or  other  restrictions  on  the  handling  of  the  document;  date;  document  title; 
name,  abbreviation,  and  any  other  identifier  for  the  system,  subsystem,  or  item  to 
which  the  document  applies;  contract  number;  CDRL  item  number;  organization  for 
which  the  document  has  been  prepared;  name  and  address  of  the  preparing 
organization;  and  distribution  statement.  For  data  in  a  database  or  other  alternative 
form,  this  information  shall  be  included  on  external  and  internal  labels  or  by  equivalent 
identification  methods. 

d.  Table  of  contents.  The  document  shall  contain  a  table  of  contents  providing  the 
number,  title,  and  page  number  of  each  titled  paragraph,  figure,  table,  and  appendix. 
For  data  in  a  database  or  other  alternative  form,  this  information  shall  consist  of  an 
internal  or  external  table  of  contents  containing  pointers  to,  or  instructions  for 
accessing,  each  paragraph,  figure,  table,  and  appendix  or  their  equivalents. 

e.  Page  numberinq/labeling.  Each  page  shall  contain  a  unique  page  number  and  display  the 
document  number,  including  version,  volume,  and  date,  as  applicable.  For  data  in  a 
database  or  other  alternative  form,  files,  screens,  or  other  entities  shall  be  assigned 
names  or  numbers  in  such  a  way  that  desired  data  can  be  indexed  and  accessed. 

f.  Response  to  tailoring  instructions.  If  a  paragraph  is  tailored  out  of  this  DID,  the 
resulting  document  shall  contain  the  corresponding  paragraph  number  and  title,  followed 
by  "This  paragraph  has  been  tailored  out."  For  data  in  a  database  or  other  alternative 
form,  this  representation  need  occur  only  in  the  table  of  contents  or  equivalent. 

g.  Multiple  paragraphs  and  subparagraphs.  Any  section,  paragraph,  or  subparagraph  in 
this  DID  may  be  written  as  multiple  paragraphs  or  subparagraphs  to  enhance  readability. 

h.  Standard  data  descriptions.  If  a  data  description  required  by  this  DID  has  been 
published  in  a  standard  data  element  dictionary  specified  in  the  contract,  reference  to 
an  entry  in  that  dictionary  is  preferred  over  including  the  description  itself. 

i.  Substitution  of  existing  documents.  Commercial  or  other  existing  documents  may  be 
substituted  for  all  or  part  of  the  document  if  they  contain  the  required  data. 

10.2  Content  requirements.  Content  requirements  begin  on  the  following  page.  The 
numbers  shown  designate  the  paragraph  numbers  to  be  used  in  the  document.  Each  such 
number  is  understood  to  have  the  prefix  "10.2"  within  this  DID.  For  example,  the  paragraph 
numbered  1.1  is  understood  to  be  paragraph  10.2.1.1  within  this  DID. 
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10.  PREPARATION  INSTRUCTIONS  --  10.2  Content  Requirements  (continued) 

1.  Scope.  This  section  shall  be  divided  into  the  following  paragraphs. 

1.1  Identification.  This  paragraph  shall  contain  a  full  identification  of  the  system  and  the 
software  to  which  this  document  applies,  including,  as  applicable,  identification  number(s), 
title(s),  abbreviation(s),  version  number(s),  and  release  number(s).  It  shall  also  identify  the 
intended  recipients  of  the  SVD  to  the  extent  that  this  identification  affects  the  contents  of  the 
software  released  (for  example,  source  code  may  not  be  released  to  all  recipients.) 

1 .2  System  overview.  This  paragraph  shall  briefly  state  the  purpose  of  the  system  and  the 
software  to  which  this  document  applies.  It  shall  describe  the  general  nature  of  the  system 
and  software;  summarize  the  history  of  system  development,  operation,  and  maintenance; 
identify  the  project  sponsor,  acquirer,  user,  developer,  and  support  agencies;  identify  current 
and  planned  operating  sites;  and  list  other  relevant  documents. 

1 .3  Document  overview.  This  paragraph  shall  summarize  the  purpose  and  contents  of  this 
document  and  shall  describe  any  security  or  privacy  considerations  associated  with  its  use. 

2.  Referenced  documents.  This  section  shall  list  the  number,  title,  revision,  and  date  of  all 
documents  referenced  in  this  document.  This  section  shall  also  identify  the  source  for  all 
documents  not  available  through  normal  Government  stocking  activities. 

3.  Version  description.  This  section  shall  be  divided  into  the  following  paragraphs. 

3.1  Inventory  of  materials  released.  This  paragraph  shall  list  by  identifying  numbers,  titles, 
abbreviations,  dates,  version  numbers,  and  release  numbers,  as  applicable,  all  physical  media 
(for  example,  listings,  tapes,  disks)  and  associated  documentation  that  make  up  the  software 
version  being  released.  It  shall  include  applicable  security  and  privacy  considerations  for  these 
items,  safeguards  for  handling  them,  such  as  concerns  for  static  and  magnetic  fields,  and 
instructions  and  restrictions  regarding  duplication  and  license  provisions. 

3.2  Inventory  of  software  contents.  This  paragraph  shall  list  by  identifying  numbers,  titles, 
abbreviations,  dates,  version  numbers,  and  release  numbers,  as  applicable,  all  computer  files 
that  make  up  the  software  version  being  released.  Any  applicable  security  and  privacy 
considerations  shall  be  included. 

3.3  Changes  installed.  This  paragraph  shall  contain  a  list  of  all  changes  incorporated  into  the 
software  version  since  the  previous  version.  If  change  classes  have  been  used,  such  as  the 
Class  I/Class  II  changes  in  MIL-STD-973,  the  changes  shall  be  separated  into  these  classes. 
This  paragraph  shall  identify,  as  applicable,  the  problem  reports,  change  proposals,  and 
change  notices  associated  with  each  change  and  the  effects,  if  any,  of  each  change  on 
system  operation  and  on  interfaces  with  other  hardware  and  software.  This  paragraph  does 
not  apply  to  the  initial  software  version. 

3.4  Adaptation  data.  This  paragraph  shall  identify  or  reference  all  unique-to-site  data 
contained  in  the  software  version.  For  software  versions  after  the  first,  this  paragraph  shall 
describe  changes  made  to  the  adaptation  data. 
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10.  PREPARATION  INSTRUCTIONS --  10.2  Content  Requirements  (continued) 

3.5  Related  documents.  This  paragraph  shall  list  by  identifying  numbers,  titles, 
abbreviations,  dates,  version  numbers,  and  release  numbers,  as  applicable,  all  documents 
pertinent  to  the  software  version  being  released  but  not  included  in  the  release. 

3.6  Installation  instructions.  This  paragraph  shall  provide  or  reference  the  following 
information,  as  applicable: 

a.  Instructions  for  installing  the  software  version 

b.  Identification  of  other  changes  that  have  to  be  installed  for  this  version  to  be  used, 
including  site-unique  adaptation  data  not  included  in  the  software  version 

c.  Security,  privacy,  or  safety  precautions  relevant  to  the  installation 

d.  Procedures  for  determining  whether  the  version  has  been  installed  properly 

e.  A  point  of  contact  to  be  consulted  if  there  are  problems  or  questions  with  the 
installation 

3.7  Possible  problems  and  known  errors.  This  paragraph  shall  identify  any  possible  problems 
or  known  errors  with  the  software  version  at  the  time  of  release,  any  steps  being  taken  to 
resolve  the  problems  or  errors,  and  instructions  (either  directly  or  by  reference)  for 
recognizing,  avoiding,  correcting,  or  otherwise  handling  each  one.  The  information  presented 
shall  be  appropriate  to  the  intended  recipient  of  the  SVD  (for  example,  a  user  agency  may 
need  advice  on  avoiding  errors,  a  support  agency  on  correcting  them). 

4.  Notes.  This  section  shall  contain  any  general  information  that  aids  in  understanding  this 
document  (e.g.,  background  information,  glossary,  rationale).  This  section  shall  include  an 
alphabetical  listing  of  all  acronyms,  abbreviations,  and  their  meanings  as  used  in  this 
document  and  a  list  of  any  terms  and  definitions  needed  to  understand  this  document. 

A.  Appendixes.  Appendixes  may  be  used  to  provide  information  published  separately  for 
convenience  in  document  maintenance  (e.g.,  charts,  classified  data).  As  applicable,  each 
appendix  shall  be  referenced  in  the  main  body  of  the  document  where  the  data  would  normally 
have  been  provided.  Appendixes  may  be  bound  as  separate  documents  for  ease  in  handling. 
Appendixes  shall  be  lettered  alphabetically  (A,  B,  etc.). 


